Open nils-werner opened 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.
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.
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.
The obligatory To-Do list :)
I've got a wishlist app on the go.
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.