What should we do first? #4
Comments
|
This sounds very good to me. |
|
Regarding the GUI, I think that we will be able to simplify and reduce it when building it from scratch with modern interface concepts and possibilities. So additional to your proposal, Nils, what about creating a static Symphony Next user interface in parallel? The ideal one, without having to think about the implementation first. Maybe this will open our eyes for better and easier approaches on both sides because we are leaving old trails. |
|
What we should, and will do, first is define the project, not think about programming of any kind yet. |
|
I actually think the first thing we should do is to redefine the key-aspects of Symphony, namely sections and fields. Especially how to realize the concepts of fields in a ORM context. When you translate the current fields concept to a ORM you'll see that one field is a model that stores just one information (field) which is actually a bit of a drawback in terms of performance and stuff. So, rethinking this may come to the conclusion that a section might be the actual model and a field is just an attribute. On the other hand, if we are going to stick with the current concept of managing fields and sections, we should redefine the section concept as it was proposed for Symphony 2.4, namely getting sections out of the database as they're "just" a simple configuration object that can be handled by configuration (e.g. xml, yaml, json whatever). Speaking of controllers: we need to separate backend and frontend controllers. Backend controllers should actually be all pretty much the same, because it's all about creating, updating, and deleting stuff. So there will be one controller per aspect, e.g. Handling controller for the frontend is a bit trickier. How should we do this? One controller per route/page? Or is there one "MasterFrontController" for all frontend pages? And as I'm typing this @designermonkey: yes. definitely. |
|
…which in a way brings us back to "What should we do first?" |
There was the proposal in #1 to think of the backend as just another frontend. |
Yes. I am suggesting to limit the scope of our project to scaffolding. I am merely motivating it by what the framework is offering.
Ideally, the framework should allow separate apps, each with their own Models, Controllers and Views. The Backend would then become a separate "app". |
I've written my draft proposal to that effect, I would like some feedback that I'm on the right track of consensus before publishing it for editing on this wiki. The idea revolves around separating layers of concern (apps), so we would have the platform (Laravel), Symphony (API app), Admin (an app), and Frontned (another app). The thing we need to develop first is the Symphony API app, which should be completely standalone, and accept requests using REST architecture, so we can test it thoroughly using apps like Rested (mac os)... But first, like @iwyg says, we need to redefine what Symphony is from a concept perspective first. |
|
Just to clarify the above too, each 'app' is a separate entity, but we bundle ours together to run on the same instance of Laravel, but separate them out internally. This would allow anyone anywhere to query our API app as long as they follow our schema for requests. This is what I was egging at in the forum about configuration. If the user comes into the 'app' via a specific route, it should only then register the right template parser. If that's not possible, then we already have an issue. |
|
@nilshoerrmann no, not at all. The backend is just a administrative interface where you mange structure and content. As we all agreed on using a framework, both backend and frontend use the same underlying architecture. So, technically you can build frontend stuff that isn't managed through the backend.
How would this fit in a CMS context? If our goal is to manage content and structure with symphony-next, the main responsibility for the application is to create and provide models for the frontcontroller and this is where it becomes tricky: do you want structure (in terms of routes) to be handled by the CMS or is it up to the user to create it's own custom controller (which would make the cms concept obsolete). So, what I was trying to say is, a controller can be as simple as f**ck but also complex as hell. There're situations where you would require more than one controller for one baseroute e.g.
Regardless which framework we choose, the underlying HTTP resolver will be Symfony HttpFoundation. So that's pretty much settled, respectively our RESTful schema will be the one that is provided by the framework. |
|
oups, sorry :) |
|
How to Write Laravel Bundles shows what could be a solution for the "different apps" idea: Bundles can be set to handle a certain URI-prefix, carrying their own Models, Controllers and Views, making them pluggable into extisting installations. |
|
I think the concept of Sections consisting of Fields is very Symphonyesque, and it's pretty interesting to consider that this could be replaced by a single Model. This is definitely true and it maps quite well to ORM, but can we do it in a way where extensions can provide extend these Models to add more complex attributes? While we do have to define "Symphony" more, this sort of early experimentation by all is a collaborative learning process and it's a great time to just test concepts and figure out how more about how Laravel works by using it. |
By the CMS if possible. |
|
In terms of 'where should we start', I thought a basic backend that allows you to create a page, generate the page template and then the resulting controllers so you can see it in a browser would be nice. This will then lead on to let us test the drop in templating layer so the CMS builds out the correct templates ( This seems largely independent of database, authentication and sections, so I think could start as soon as anyone would like to (I know @iwyg and @nils-werner have already started tackling the renderer's, good job!) |
|
@brendo Just so you know, there are several code generator Providers that hook directly into |
|
Also...
|
|
Regarding proposals mentioning an underlying API which both the backend and frontend can use, this is pretty much what I read about how ProcessWire is built, so it'd be a good idea to have a look at this for inspiration. |
Instead of section == the model, perhaps a section is a model, but each field type is a model too. This is probably where nested objects in a noSQL db would really help: a master model and child models defining its structure. I'd like to know more about how Rails achieves this. In a model (section) you can include whatever field types you want, and gems (extensions) can expose new types. I wonder how they interact and are stored. |
|
@brendo already mentioned this in #1: it should have a build script and it should have php unittests. My 2 cents would be to say that one of the things we need to do first is setup a development environment, create a build script an plug it into Travis CI or some other build & deploy system. I would be happy to contribute to this part of the project! |
|
good point |
|
Also, what would really be nice to have is a vagrant box that easily lets you fire up your dev environment. |
|
Laravel has this already: |
|
sure, that starts the php webserver and lets you drop in very quickly, however having a vagrant/puppet setup might help with:
|
|
Just a few thoughts as I'm currently researching more advanced stuff in JavaScript... I think it's pretty future proof at this point to rely on the PSR-recommendations, Composer and Laravel on the server side. Almost all major frameworks support these recommendations and are already (or going to be soon) easily interchangeable. On the client side, jQuery won the framework wars a long time ago and has matured into a reliable and well organized project ever since, so relying on jQuery is also a pretty safe bet. With CSS preprocessors, it currently comes down to two considerable options, LESS and SASS. There's strong support for both, so they both might stick around for a while. But even if one emerges as the clear winner in the near future, it wouldn't be too hard to rewrite our Stylesheets because both are not that fundamentally different from each other regarding their syntax. What makes me feel a little sceptical at the moment is the sheer amount of shiny new JavaScript thingys all the cool kids seem to be using these days...
While most of them serve different purposes and help implementing long standing design patterns or at least promise to make things a lot easier in general, I'm not convinced that all of them will be around and widely used in two years from now, so we should choose very wisely what to use for Next and where to wait and see for the time being. |
|
not sure about angular js (it's google, so you'll never know), but ember and handlebars won't diapear in the near future. So is backbone (due to it's popularity). And as long there's no native AMD support in the browser, requirejs will also stay for a long time. |
|
Oh, and I thought there's no more active development for LESS? Or did someone else pick up that project? |
Prototype and Scriptaculous were also very popular a few years ago, now it's a pain in the ass to maintain these old projects. Just sayin' ;)
Seems pretty active. |
|
yehuda katz kinda build his business around ember (which is the successor of sproutcore), but you're right. You'll never know. |
|
Didn't want to judge any of the mentioned projects. Just feeling a little overwhelmed and wanted to make sure we make good decisions and don't just blindly jump on every hipster.js bandwagon. |
|
Yes, we should just choose the one that fints best to our needs. |
|
Should the backend work without JavaScript, or are we happy to specify JavaScript as a requirement? I ask particularly because it's been mentioned that the backend interface might act as a reference example of using Next's RESTful API. |
I joined in the group of people who persuaded cloudhead to let others manager the repository. There were loads of PRs and issues to go through, and loads more work has been done. There still isn't a next release version, but it isn't far off now. |
That is a very good question. Personally? Yes. |
|
It's best practice. So yes, the backend should work without JavaScript. |
|
+1 |
|
I guess that means no ajax and no injection of markup for extensions then? |
|
hm, why? |
|
not necessarily no ajax; I think we should at least ajaxify forms (makes the application more streamlined) but submission should work regardless. |
|
It's possible to do Sections Editor without javascript? |
|
Why not? |
|
I'm just thinking about certain rich content fields like maps and wysiwyg editors. Although these wouldn't be in the core, it would require extension developers to consider fallback options. Not that I see scriptless functionality as a bad thing, just concerned it might impose some limitations on what's possible. |
|
Progressive enhancement then: works without JS, but improved with JS. I guess for extensions it would be optional but preferred. |
|
@nilshoerrmann I don't see why not, but I'm really curious on how would that work. The no-js idea is fine, but never see any use case. |
|
I have always used progressive enhancement for any frontend work. It's cool to gain focus and do things step by step. And it simplifies (client-side) JavaScript logic. Think of items reordering, for example. You can build an HTML form with an input field for the "position number" in every row. You don't need to think about JavaScript in this step. The user may change numbers in the input fields, then submit the form. Later, you can put JavaScript on top if it, hiding the input fields, writing those numbers to the source code and maybe even submitting the form when items are dragged and dropped. Regarding AJAX: If it's implemented using progressive enhancement, you call it Hijax. And here is the other extreme: If you decide that your app should require JavaScript, you might actually take it one step further and generate all your HTML source code on the client-side using JavaScript and AJAX. I never tried that, but I heard that there are some frameworks around to help you with that. I don't see any advantages of solutions "in between" the two concepts. Do you? |
|
I think if going towards re building the backend I would prefer Hijax to using Javascript to build the HTML source. It would mean that the data in the backend rendering takes the symphony flow. Rather then a completely different structure. Mind you where I work we assume that you need Javascript for our websites/app to run properly. So form's don't quite submit without that but its a completely different use-case. |
|
If your application doesn't work without JavaScript, you're doing it wrong ;) Every page has to draw the strengths of its constituent parts. HTML has forms, so use them to query the app, they should work, however clunky, without any JavaScript or CSS. When this works, then it's time to polish it up with CSS and JavaScript. You should be able to discern the meaning of an application and its responses from its plain browser styled HTML. I always feel really bad when I don't get time in a project to make it work properly without JavaScript, it really does eat me up inside. We're building an API with a human interface, it has to work correctly at all levels of technology, albeit maybe slow and ugly to start with. |
That's the idea of frameworks like backbone and ember. Also see the emerging of various javascript templateing engines in the last years. There're also good reasons to build an application solely on javascript: because serversideness is expensive. Or look at big enterprise applications, where you have dozens of working queues running on the backend. You need javascript to track responses. Also, a well crafted JS application can have a great boost on the UX, but I guess that's what we all know here. BTW, this seems like a nice resource. http://superherojs.com/ |
|
My personal experience is that creating "a well crafted JS application" is way more complicated than building a site based on the principles of progressive enhancements. Many sites fail because you have to rebuild logic that classic HTML pages handle perfectly out of the box (think of error responses etc.). Even Github, which I consider one of the most brilliant web apps of the last years, struggles with unresponsive pages that don't give any feedback on what didn't work – and they rely on JavaScript for some of their main features. If you set up your project logically, you can easily use the same server side templates for your static HTML pages and AJAX snippets. No need for an additional template layer on the JavaScript side. One thing we have to consider: Symphony doesn't have a complex backend where JavaScript is necessary to create an impressive user experience. There are areas where things get easier with JavaScript, like animations that make a behaviour and directions clearer to the user. But we are working on a simple, reduced interface and we should keep this in mind and choose the right tools. One framework less in this context is a good choice. 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. |
|
@nilshoerrmann said
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'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 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 |
|
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.
The text was updated successfully, but these errors were encountered: