symphony-next
symphony-next copied to clipboard
symphonycms
Things it should have
Just a list of things I think Next (and the framework it is based on) should have. Feel free to append anything you think is important
- PSR-0 compliance
- composer.phar package
- ORM
- Ability to swap out the templating layer
- Builtin DB migrations
- Command Line Tool
- PHPunit/TravisCI integration
Granted, those are all features I've seen in Laravel. I am just blown away by the possibilities they offer.
Agreed,
furthermore, things that should be considered:
- scalability
- easy to use with reverse proxies
- solid approach on user handling (think of ACL)
- RESTful architecture
- Nice to have: AOP // that's actually just a personal dream :)
Am 13.04.2013 um 11:19 schrieb Nils Werner [email protected]:
Just a list of things I think Next (and the framework it is based on) should have. Feel free to append anything you think is important
PSR-0 compliance composer.phar package ORM Ability to swap out the templating layer Builtin DB migrations — Reply to this email directly or view it on GitHub.
We should finally drop the current technical separation between the frontend and the backend. Which means to still have a backend, but:
- use Members and an ACL to manage access to the backend (because having two different types of accounts seems strange)
- generate the backend with datasources, events, XML and XSLT (resp. correspondent core concepts of Next)
This would mean having one account for everything. Another advantage would be that backend code can be re-used by developers to build "interaction" in the frontend.
I have built a rather advanced administration area in my web app's frontend, so I know what I am talking about. Maybe — depending on a major rewrite of my own utilities — I could contribute XSLT code to auto-generate publishing forms, including field-level validation. This layer should be super-elegant in the end, so it won't be a simple task. But it might be a killer feature if the provided XSLT code could be used in the backend and in the frontend, simply because HTML forms are the pest, and validating data is even worse. So, add another point:
- provide a re-usable XSLT template layer for any kind of "publishing", i.e. forms.
By writing this layer in XSLT exclusively we would follow @nilshoerrmann's proposal from the forum, making XSLT the "pro choice" for the frontend and the sole backend template language. I like this proposal.
RESTful architecture
@iwyg I'm so glad you said that, excited even. I've been drafting my version of a proposal for a couple of days, and that word, REST, features very heavily in it.
I'd like to second Michael's proposal to consider the administration area just another frontend of a site. This would also make the backend a blueprint for complex web apps that could use Symphony as a starting point for their own service.
Using Symphony to build Symphony will also make sure that the API is tested and working and not lacking features as it currently does. In this context, we should make sure that the visual interface is representing all functions available in the API. As a designer, I don't want to leave the UI and touch PHP files (something you even have to do for simple negations in Data Sources right now).
Furthermore, we should consolidate fields. I hate the concept of "core extensions". We are either dealing with the core or with extensions - there is no middle ground. Things considered essential should be part of the core itself, the rest should not be bundled with a release. From my experience, "core extension" fixes have only landed short before a Symphony release or even required a Symphony beta to work, so we should not make things harder by separating stuff. We should rethink the most essential fields and make sure they share the same settings (requirements, uniqueness, multiple values). The core field's UI should be kept simple but not dumb. Symphony 1.7 bundled a really simple, really nice calendar - I did never understand why it was dropped because it ensured valid dates. We really should look at some lovely ideas that existed in earlier versions.
Ah and finally, to not look stupid here, we should make sure to base everything on ROTFL and WTF to make things more ROLEEYESful.
Addendum: Regarding the interface, we should make sure to not reinvent the wheel. The should have a look at existing JS plugins and professional web app libraries like backbone.js and the like.
We already have an interface, so we should use the same markup, js and css to save time for the first release IMO.
It would save us a lot of time thinking about the UI organisation now and not later. Symphony 2.3 is quite messy due to compatibility decisions. It would not steal us any time by the way because those working on the UI are not the ones working on the underlying PHP core.
We already have an interface, so we should use the same markup, js and css to save time
Nope. I am with Nils here: Do it right if you get the chance.
I'm sorry, I don't understand. What compatibility issues were there? We dropped support for older IE in 2.3, so I thought all of the issues were taken care of?
We have left a lot of things the way they were in order to keep extensions up and running. Think about Duplicators, localisations etc. The way we handle backend views in admin.js is not very professional.
By the way, rewriting the backend in a new envirinment is a great moment to think about a few essential interactions: Do we really need a dedicated section editor or couldn't this be better handled inline, within the content area? Why do I have to reorder a table to change the backend navigation and navigation groups, if I also could do editing in the navigation directly?
Agreed.
Am 14.04.2013 um 12:36 schrieb michael-e [email protected]:
We already have an interface, so we should use the same markup, js and css to save time
Nope. I am with Nils here: Do it right if you get the chance.
— Reply to this email directly or view it on GitHub.
Maybe a bit premature, but building the backend UI on a Javascript MVC framework could save a lot of time and effort. A RESTful application architecture (think of laravel's Resource controller) would give us the tools at hand to do so.
This also may drop the necessity for a dedicated templating language for the backend since all or most rendering would be client side.
Am 14.04.2013 um 13:05 schrieb Nils Hörrmann [email protected]:
By the way, rewriting the backend in a new envirinment is a great moment to think about a few essential interactions: Do we really need a dedicated section editor or couldn't this be better handled inline, within the content area? Why do I have to reorder a table to change the backend navigation and navigation groups, if I also could do editing in the navigation directly?
— Reply to this email directly or view it on GitHub.
But this would make @nilshoerrmann's (and my) arguments useless:
This would also make the backend a blueprint for complex web apps that could use Symphony as a starting point for their own service.
Using Symphony to build Symphony will also make sure that the API is tested and working and not lacking features as it currently does.
Both would be a big plus.
+1 for a fresh start with the backend interface. I imagine there will potentially be quite a few fairly fundamental changes made in underlying functionality/approach, such as the one @nilshoerrmann outlined, and we don't want to have to worry about fitting in with a previous version's markup structure, CSS and JS. There may also be improvements/changes in structure the UI people want to make to CSS, etc.
But maybe this is a topic for another issue/thread, with this issue being more of a broad list of features it should have rather than implementation details? I have some questions/suggestions to pose/make on the admin area, which I'll probably start a new issue or two for.
BTW, can we move the discussion to something other than e-mail?
Am 14.04.2013 um 13:42 schrieb David Oliver [email protected]:
+1 for a fresh start with the backend interface. I imagine there will potentially be quite a few fairly fundamental changes made in underlying functionality/approach, such as the one @nilshoerrmann outlined, and we don't want to have to worry about fitting in with a previous version's markup structure, CSS and JS. There may also be improvements/changes in structure the UI people want to make to CSS, etc.
But maybe this is a topic for another issue/thread, with this issue being more of a broad list of features it should have rather than implementation details? I have some questions/suggestions to pose/make on the admin area, which I'll probably start a new issue or two for.
— Reply to this email directly or view it on GitHub.
@iwyg, this discussion is already at Github: https://github.com/symphonycms/symphony-next/issues/1
- Unit testing for everything. This saves hours and hours when trying to package new releases
- A build script. This will save time when packaging a new release
- One CSS and One JS file for Symphony. We can have multiple files in development, but the build script will combine them for distribution. This is best practice and if you've ever used Symphony in a shared hosting environment or on a poor connection, you'll agree
- Better scalability support for cloud hosting
- A plug n' play architecture for core components like templating, databases, caching, logging (PSR-3), email etc.
- A Profiler that makes sense and produces information that everyone can understand
- A Debugger that has state and syntax highlights on the client, so the server is not slowed down
- A more seamless integration of publishing for the frontend and backend
- Flexible fields that can be migrated to other types
PSR-0 compliance
Why no PSR-2 compliance? Or at least follow Laravel's guidelines, which include PSR-1.
- The goals for Symphony 2.4 (structure stored in files, only content in the database) should remain intact.
- Also it would be interesting for smaller, mostly static sites to store the content itself on the file system, like seen in systems like Statamic or Kirby. Maybe a SQLite database would be a good compromise without too much additional complexity?
The goals for Symphony 2.4 (structure stored in files, only content in the database) should remain intact.
Apparently, nowadays you don't save the actual DB structure but only its changes (migrations) from one version to another in your files.
The first migration creates the table, all following ones only change or drop it.
The first migration creates the table, all following ones only change or drop it.
Not sure if I get this. Like Database Synchroniser?
Laravel 4: Migrations and Seeding. It lets developers and sysadmins easily update database structure based on version controlled code.
But I haven't got my head round whether or not Symphony's sections could/should use this...
The gist of it: For each change to the DB structure you create a "migration", identified by a date (and inherently its place in the ordered list of migrations). The database knows which migration ran last and your migration script can find out if there are any new migrations available. Only those will be applied (in the right order, obviously) when you migrate.
So instead of having a smart algorithm that knows how to manipulate your table to end up with what you want you tell it exactly what to manipulate.
Another benefit of using Laravel 4: Migrations and Seeding is that it allows you to rollback if needed.
Yep, just like Database Synchroniser, only cleaner. You don't need to store the actual SQL commands themselves, instead a meta language describing the process e.g. "Add column "title" to Posts".
After having used Rails for a year, if I returned to using Symphony daily I'd miss:
- migrations when using an SQL db (not needed for noSQL)
- the ability to choose noSQL if I want (note: this does NOT mean I can just swap them at any time. When using mongo I still query as mongo queries (inc. map/reduce), and when using SQL I still write some queries using the SQL syntax of that db. This is unavoidable and expected. Do not waste time aiming for 100% db abstraction is it is not achievable)
- ORM! I haven't written an insert/update in 14 months. Leads me to...
- MVC! Symphony is already close, so enforce it. With Rails we have ActiveRecord which is the ORM (this is where model relationships happen), and then something like Mongoid which is the database mapper. Keep the class-based ORM and the db mapper separate
- I'd miss ERB. I don't miss XSLT. We loved XSLT because XPath made cross-referencing nodesets easy (e.g. for combining the output of two DS). But having a controller pass you properly nested model classes in the first place means your views remain light anyway! Loops and variables.
- routing! In code! It's just a config file I can edit
- no restrictive UI! Symphony gets clunky when you want to do complex things, because everything had to have a UI. Writing a model in ruby I have a very clean syntax for defining its fields, how it should validate, how it should persist (if I want to), and how it relates to other models (see ActiveRecord). No UI restricting how I work, meaning validators can have numerous options without needing a UI to support them
- the asset pipeline. Automagically process my SASS, concats and minifies my files and revs file names in production to cachebust
- localisation of site furniture (labels etc) is really easy using yaml files
- config files are split into environments for dead simple management, and deployment with Capistrano is a joy
I'm sure there are more but this is my starter.
Some other ideas:
- SQL is fine. You don't need noSQL. But get ORM and relationships right!
- if you're aiming more at developers, provide command line tools and assume they are comfortable writing object oriented PHP under MVC: don't try to UI the lot. We are developers, we use a text editor all day. Developers in general are getting more savvy (git, command line etc) and this will only improve. I'd consider no UI for sections, pages and data sources.
There are two "backend UIs" for Rails. I forget their names. But they provide a super easy DSL for defining your UI. Just add anew rules to your models (sections) and you get a sortable, filterable table UI. I know Symphony is more than this, but I think they're good inspiration for the power that code-only affords. Lets you focus on Symphony being the UI for content management, not Symphony being the UI to build the UI for content management :-)
@nickdunn I agree. That's why I suggested to do scaffolding first, then take a hard look if we need UI for structure-maintenance at all (and if somebody wants them, keep them separate from the scaffolding).