Ok, I hate to double post, but I just realized that what I wrote in the beta release news area should have gone here. :-"
Anyway, these are some of the ideas and questions that I have had since I've been playing with the new beta.
Congrats on the new Alpha!
It definitely runs better than the previous cvs release that was taken down wayyyyy back in time. thumbsup.gif
Well, all do we as a community just sit here and flood the team with just a few comments and congratulations or do we bother and chip in with our thoughts?
I did see the bit on the over ride and attributes. Definitely something that is a plus!!! biggrin.gif
I'm going to throw in some questions and constructive critisms.
1. Why xml for languages? I have hacked the cvs November 30, 2005 version and ran the results out to the cache. Reasoning was that then you could change wordings from the admin rather deal with ftp. errr, I'm a bit old school here so forgive my ignorance towards xml.
2. Why the sheer amount of wordings for each and every area? ie, "total" wouldn't it be better just to trim the amount of language down and recommend not coming up with new naming conventions like "ACCOUNT_TABLE_SUBCHART_RIGHT_TEXT_TOTAL". I had gone through the older cvs and got the core down to about 125 rows and figure that I'd end up at under 200 different "TEXT_SOMETHING" for translations.
3. Why name the language definitions based on the page or area? I'm just trying to cut down on bloat.
4. How about moving the filenames to the db? Then you could work with FILENAME_SOMETHING rather than with "require 'includes/application_top.php' " and could just run with "require FILENAME_APPLICATION_TOP". The benefit is that this would be cahced and could be easily updated from the admin allowing easy directory movement in future releases.
5. How about a cleaner directory structure? I figured that you could modularize everything into there own areas which does cause havoc to the current "slurp files in X directory" technique. But it does allow developers to work in their own sandbox area. I was thinking that maybe registering the modules in the db would be better than just slurping what's in X directory.
6. Turning the index.php page into a work horse engine versus just a one off show. This ties into the directory sturucture idea. You could call index.php?account&module=info instead of having to call each page separate; account.php?info
7. cutting the fat. I was thinking that osc should be a lot leener than it is now. Pass off some of the work to developers/contributors or even outside projects. Sure banners are nice but should they be part of the core API? Basically, what I'm thinking here is a super lean minimum machine that can juiced up to fit whatever needs the end user has rather than try to provide a bloated package like zencart.
8. look at some other non-relevant packages. I'm become a huge fan of ModX - cms/framework they've got some cool things going on. Like snippets and Template variables that run through a pretty dang good parser that let's you do bascially any type of template. In some ways osc could benefit from something like that!
9. open the API up to communicate with other outside packages. Like forums, cms frameworks, banner programs, stat programs, etc ... Sure you can work with contributions but imagine that you get other communities to help with the low level API communication work a lot of people would benefit. This would also open osc to WEB 2.0 (referring to web 2.0 as larger shared standard rather than ajax and moo!)
10. time lines. hmmmm, I can see why things get delayed. Hey, that's programming for you. I was thinking that maybe sometimes posting something like, "sorry folks, development is getting delayed by personal time issues "trips and parties" please bare with us." Or something like that. The team is human and so are we biggrin.gif hehe, it's pretty hard to code with a buzz .... errrr .... whistling.gif no, but in the morning I can never figure out what or why I did that tongue.gif
11. How about another layer between the developers and the forum users. Like a small team of: beta testers, code hackers, translators and foreign language moderators, contributors, people with no-technical skill but ideas and other abilities, etc. Basically, open up the inside to the team just one level.
12 .... anything else?
@ hacking the core
In many ways I agree. A lot of mods affect the way core files work. BUT that is because that is the way those core files are coded. tongue.gif ( Just being realistic -- not trying to offend but truthful).
I mentioned nearly 3 years ago about hooks / events. Xaraya and Postnuke were the 2 systems that I do believe that I brought up.
Now, today, in my post above. I mentioned ModX / Etomite (just 2 systems that I know who do this ... not sure if others do or not). But they allow you to write bits of HTML / PHP code that is saved into the db which is parsed on it's way out. This is really awesome sh*t (sorry for the enthusiasim) but anyway, this might be another way to prevent tapping into the core files for a lot of cases.
event triggers + on the fly code parsing
I'd gamble a bit here but would say that this would do for a lot. Then when situations do arise, either a .point release could be made and all benefit or the end user goes off on their own custom system.
Just an idea blush.gif