symphonycms / symphony-next

The next big thing.
19 stars 1 forks source link

What should we do first? #4

Open nils-werner opened 11 years ago

nils-werner commented 11 years ago

Especially in the Database-, Model and Controller-layers, most frameworks do things differently than Symphony. Radically different in fact.

They are easy to be programmed by hand, but hard to be generated using a GUI. Symphony on the other hand uses lots of GUIs and makes it incredibly hard to do things by hand. Also, most of us don't know yet how frameworks actually do that stuff.

So in my opinion we should put the "database- and controller-management by GUI" concept last. The first thing to create would be a "scaffolding" bundle. One that lets you edit the data in the models you already have in your framework. Given that model and controller-programming is easier to do by hand, this bundle would be the most useful feature for endusers (also for users new to Symphony) and would have the most limited scope, assuring that it will actually be finished in reasonable time.

Additionally by doing that, we will gain experience how the framework works and will end up with knowledge, if and what kind of controller/model-managing-GUI will be necessary.

vlad-ghita commented 11 years ago

@nilshoerrmann said

The main two problems of the admin scripts are code organisation and state handling (Which page am I on and which functions do I need there?). If we solve this, we've done a good job.

At work I'm currently building a Frontend Admin for Symphony using Resources concept for code organisation and it works. Creating / Editing entries while inside other entries is a breeze.

@michael-e said

I don't see any advantages of solutions "in between" the two concepts. Do

I'm using exactly a solution in between, trying to generate as much code in XSLT and using Handlebars only for really, really simple tasks required by AJAX.

Edit:

Doing this only server side, without JS, won't work. For easy using and interaction, JS & AJAX are mandatory. Imho, as much code as possible should be generated with XSLT server side and JS should take over only where UI requires it.

jonmifsud commented 11 years ago

agree with @vlad-ghita if you want easy interface & interaction JS & Ajax is a must. (not saying it shouldn't work without but for sure you can't achieve the same levels of integration.

Example : Imagine using something like Sub Section Manager or FileManager without JS. would be quite hard to do.

I remember in the relationship discussion; it was mentioned that the 'view' had to be improved. Surely one can provide the default select box and the improved version but It could also mean double the work when it comes to integration.

iwyg commented 11 years ago

Was messing around with something. This might be interesting for bootstrapping sections etc. from xml files

https://github.com/iwyg/xmlconf

Experience some weird issues with travis-ci though.

iwyg commented 11 years ago

The obligatory To-Do list :)

DavidOliver commented 11 years ago

I've got a wishlist app on the go.