Things it should have

[nils-werner]

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.

[iwyg]

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 notifications@github.com:

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.

[michael-e]

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.

[designermonkey]

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.

[nilshoerrmann]

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.

[nilshoerrmann]

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.

[designermonkey]

We already have an interface, so we should use the same markup, js and css to save time for the first release IMO.

[nilshoerrmann]

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.

[michael-e]

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.

[designermonkey]

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?

[nilshoerrmann]

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.

[nilshoerrmann]

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?

[iwyg]

Agreed.

Am 14.04.2013 um 12:36 schrieb michael-e notifications@github.com:

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.

[iwyg]

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 notifications@github.com:

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.

[michael-e]

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.

[nilshoerrmann]

I'm not a fan of building the backend using JavaScript only.

[DavidOliver]

+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.

[iwyg]

BTW, can we move the discussion to something other than e-mail?

Am 14.04.2013 um 13:42 schrieb David Oliver notifications@github.com:

+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.

[DavidOliver]

@iwyg, this discussion is already at Github: https://github.com/symphonycms/symphony-next/issues/1

[iwyg]

m( vanish

[brendo]

• 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

[designermonkey]

I threw together the beginnings of a project proposal.

[jensscherbl]

PSR-0 compliance

Why no PSR-2 compliance? Or at least follow Laravel's guidelines, which include PSR-1.

[jensscherbl]

• 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?

[nils-werner]

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.

[jensscherbl]

The first migration creates the table, all following ones only change or drop it.

Not sure if I get this. Like Database Synchroniser?

[DavidOliver]

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...

[nils-werner]

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.

[lewiswharf]

Another benefit of using Laravel 4: Migrations and Seeding is that it allows you to rollback if needed.

[nickdunn]

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 :-)

[nils-werner]

@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).

[nickdunn]

http://activeadmin.info/

[nickdunn]

Ah ok, didn't see the other thread. Yup.

[michael-e]

@nickdunn: Nice to see you. And thank you for your insights.

I didn't dare to suggest the "no UI for DSs, events etc." thingie, but I am glad that you mentioned it, because I agree with what you say. If I could only code my ideas in a straight and simple way, I wouldn't even miss the UI.

[lewiswharf]

http://activeadmin.info/

Looks brilliant. I agree with @nils-werner and @nickdunn

[nilshoerrmann]

Who's that Dunn and what's he doing here? :)

Just my two cents: I'm not a developer. I'm an author and designer. So I don't want to code, I don't want to leave the user interface. I want the backend make me forget that there is PHP at all.

Symphony attracted a lot of designers in the old days. If we need to start coding for a simple DS or event, we are off. Don't forget about us. I have cursed Symphony more than once because I had to edit PHP files to not execute a DS if a parameter was present. If Symphony doesn't provide an outstanding UI for this, good bye.

[michael-e]

I don't think that this is entirely true. Symphony's attraction comes from "making it super-simple (to define sections, fields, datasources etc.)" Does this necessarily mean "having a GUI"?

Only if it's hard to code it (like it is currently, and it has always been) Symphony should have a GUI. But imagine a simple syntax to do your things — you might be more productive, and you wouldn't hit the GUI barriers. Compare it to XSLT — you wouldn't want to have a GUI for that, would you?

[michael-e]

[@nils-werner's proposal]((https://github.com/symphonycms/symphony-next/issues/1#issuecomment-16400838) is great. If we do it that way, we will learn a lot. I am rather sure that we will be tuned to the same wavelength then.

[nilshoerrmann]

If I'd want to write code, I'd use Laravel directly and would build a frontend form for those areas I'd need it. Templating and settings are two different things in this context in my eyes.

Removing DS and events from the interface wouldn't make a difference for programmers: they write custom code anyway and Laravel will make that easy. For everyone else things get worse: another thing to learn, another barrier. It's like telling the baker to raise his wheat first: that's not what he want's to do.

Please just don't forget that you are a small group of euphoric webdevs seeing a new perspective for Symphony. And don't forget that there are a lot of users with other needs and different knowledge.

And by the way: we don't need to recreate Rails - it's there, just use it!

[michael-e]

I just say: Wait until we see it. :-)

[lewiswharf]

That's why I suggested to do scaffolding first

I agree.

[iwyg]

Yes, we have to very careful not to build another framework on top of a framework.

@nilshoerrmann I understand your worries, but wouldn't it be pretty much the same than it is now with symphony and the DS Editor? Sometimes you just have to hit your editor of choice and start hacking because you can't get certain things done due to the UI restrictions (think of the most video converter GUI's, there'e almost all crap because they really just hit the surface of what you could really do with e.g libvpx, ffmpeg etc.).

I think we are just trying to make things more easier and cleaner when it comes to coding. But don't worry, we also can do amazing things that are GUI based using scaffolding and stubs (just like it is now, but maybe a bit more sophisticated and more flexible).

[nilshoerrmann]

I'm not talking about complex requirements, I'm talking about trivial things like negations etc.

If it will be easy to write custom DS and events, it will be easy to create an UI for it. We don't know how both sides will look but we should not abandon the UI because most participants here don't think they need it. You (the devs) can ignore it for know and it's up to us (the designers) to imagine it but the UI is an important selling point of the system.

[iwyg]

Yes, that's true and I fully agree.

[lewiswharf]

You (the devs) can ignore it for know and it's up to us (the designers) to imagine it but the UI is an important selling point of the system.

Agreed. Form follows function.

[loremipson]

You (the devs) can ignore it for know and it's up to us (the designers) to imagine it but the UI is an important selling point of the system.

I love the xslt side of things with Symphony, but I would get rid of that way before I got rid of the UI for datasources, events, etc. And that's considering that you'd have to pull my teeth to get rid of xslt. No UI would kill it for me. I wouldn't be able to use Symphony without it.

[michael-e]

the UI is an important selling point of the system

I never showed the datasource or section editor to my clients. Did you do this? (Please keep in mind that @nickdunn was talking about the developer stuff, not the authors' "publish" stuff.)

Anyway, please slow down. @nils-werner's proposal was to do other things first. He is right. @nickdunn tried to help us by giving us valuable insights (of a "developer", maybe). And all I say is: Assumed that writing code would be as simple as clicking around, I wouldn't miss a GUI. But this point doesn't need a consensus now. On the contrary, we would be fools to have one, because nobody can foresee what we will actually build (and what will be possible). So let's stop this discussion, please, we are wasting our time.

[s-e]

I'm going to throw 2p into this one if that's okay?

While I agree that a code-driven framework for things like datasources should be the first aspect of them to be developed, I understand where Nils is coming from here. Code can be intimidating, even if it's actually super simple once you do some research on the API.

One of the benefits of having a GUI is that you can start playing around without having to do much in the way of that research. All the options are presented to you to examine visually.

Having said that, as long as there is a solid foundation in the datasource API in code when it is developed, shouldn't it be straightforward to drop a GUI on top of that, even if it is limited when compared to the full code version?

[michael-e]

Thanks, I agree with everything. (I myself was attracted by Symphony's GUI possibilities many years ago. I didn't know anything about PHP at that time.)

We should just build the foundation first. Make coding as simple, powerful and enchanting as possible, then try and build the best GUI for it!

[iwyg]

yep

[allen]

Agree with everything. Just adding my thoughts on GUI:

GUI gives inherent structure to configurable controls, which is a great benefit for users that are either new or developers returning to Symphony after being away for a while without having to depend entirely on reference material.