Here is my sort of brainstorm for some of the coding aspects we should pay attention to:
– MVC setup
Best coding style now I think, very organized, and works well with only one directory in the webroot.
– Cacheing System
vb4 as many have already noticed is SLOW. We need our engine to be quick and light. We can do this and still have tons of modules/widgets running by caching all the data. Modules/Widgets will have a function that runs that takes the settings the admin set and caches the data thats needed that way data can be pulled with only one query
Views: 30
avoiding the usage of {username} or {userid} in every piece of script is a good way to cache content without problem… having to identify the visitors all the time in any situation is 1-pointless, 2-uncachable …
To avoid IBs HUGE mistake we shouldn’t post any screen shots until that feature is finalized so we avoid the Kier situation. Also we should definitely hire a designer to make a professional skin for our system vbulletins is just horrible.
i actually have 2 great designers with us… one that is my own brazilian cutie, and the other is actually in the dark, would be trouble for him to show right now.
and the day i have screenies is when it’s complete… what i think is that we will deliver a « demo » the day we deliver the project, and we will have some official demos, our own personal sites for each of us… different styles, each designed and available by the project.
Yeah I need a new system for my site so that’d work perfectly
Ok I think I have come up with the idea for the perfect layout manager..
First we have the shell template. This sets up the basic layout (header, footer, container, etc). This can only be edited via template file.
Then we have « setup templates ». These templates are just basic divs that are (for example) one column, two columns, one row up top then two columns below, etc. Then when admins are editing or creating a page they can choose which setup template they want to use. Then finally the widget/module templates go in the setup templates columns or rows. The columns and rows in the setup templates will also have ids that match up across setup templates like « left_col », « right_col », « top_row », etc. This will allow designers to add css like:
#left_col .widget { specific css for left columns widgets } [/CODE]
This is customizable, simple, and can be extended.[CODE]#left_col .widget { specific css for left columns widgets } [/CODE]
This is customizable, simple, and can be extended.
yeap, this is also way more flexible that this, as we do it in a specific way for the structure and then for the content:
the only thing is that it will be hard to find the right script in ajax to switch the style while we let the users move elements around… *(cutosmizing their profile etc)
I already made a YUI 3 script that allows you to drag and drop 🙂 and saving is nothing.. We just add the file for the script and say which divs have draggable elements and then movable.. 😉
Also with the set up idea we can make it so developers can make there own for complexe designs
sure, i want the devs/designers to have a complete engine to work with, so they do not have to create a « functions.php » like we see in wordpress *(pointless technique if we offer a real sdk)
Yeah… Another idea I was playing with is instead of having: require(DIR . whatever).. We make a function called ‘Loader’ in the loader class you say ‘include’ or ‘require’, what you’re loading (template, class, etc.), and of course filename. This would give us a lot more control over files out of the webroot.
yeap… è;)
Also here is what I think we should do for file structure:
./webroot/
This is where we will have an index.php that handles all requests and sets up the base engine. We also have a folder for JavaScript and CSS in this directory.
../application/
This is the directory that has templates, widget files, forum types, etc. Anything that we know developers will make more of. This is also where our config file will go.
../Library/
This is our core, or all the files we want to just set up everything and nothing else so we don’t have developers editing it. All core classes like database setup, template processor, and widget processors go here. For things like database where we might have multiple class (different types of databases) we make a new folder called ‘Dbs’ to keep it organized.
looks like the BSD structure to me.. 🙂 good structure!
btw, you have to remember that the only enhanced way to do it is by providing independancy for all sites you handle under the system… if the guy have only one site, that’s easy, but we have to count numbers of sites under the same location, and avoid overwriting the files already existing on a server.
we can always have that kind of structure for each client:
/cache
/usr
/tmp
/lib
/store
/ext
/xml
… ya know, named the unix way is good for recognition… and each client will see its custom files stored in its own directory, so the WHM engine or anyother will detect the correct storage space .
Yeah I forget a cache directory we’d need that. As far as multiple sites the /Library/ would never change so that could be used, and we could have the /Application/ directory be called /Application_vbe/ where the _vbe is replaced with an abbreviation setup for the site.