Search

I hope this is not inappropriate to ask, but I wish to put the feelers out...

  • Would anyone be interested to be involved in creating an express.js (node.js) cms system based on the many of the principles, patterns and designs used in Symphony-CMS?
  • Would anyone be offended if the Symphony-CMS project was to be in part recreated in JavaScript?
  • Is it possible with the current license to use assets from the Symphony-CMS project for such a system (especially the Backend HTML/CSS, Field Designs)? Would anyone not like this to happen?

I hope this thread does not sit dead and gather dust but if anyone is interested to know more about why express.js is suitable building block I am happy to expand on this. It could at very least be an interesting experiment...

Thanks, Ross

I think I still have problem accepting Javascript as a back-end scripting language, even though it has high potential. Personally I think creating such an advanced application in Javascript is difficult, given the loose typing you will have a hard time making sure you are not creating a mess.

I'm definitely interested to see the results of your effort. Unfortunately I don't have time to participate. I cannot comment on whether or not it is allowed to use the Symphony look and feel.

No aversion. But I'd question why. If it's "just because" then I see no point: different technology, same result. You should certainly aim to solve some of the architectural problems in Symphony so that the product you create is an improvement and not simply a port.

@remie Thanks for you input, there is certianly a valid discussion whether JS is currently suitable for backend development however I believe JS as a backend technology inevitable. It is a script language as much as PHP.

@nickdunn the purpose of doing so would be to streamline front end, back end AND server technology into using as single language, and enable the use of other node based server technologies.

We use symphony quite extensively mainly because the its backend usability and the speed/ease of which a website structure can be created, great. However the principles of XML data sources & XSL templating would be very much suited to JSON and JS templating too. Also, people with knowledge of XSL are few and far between and I find the problematic.

Not saying a Symphony equivalent could be created over night, or over a year and I have seem many custom CMS projects fail. But if such a project were to go ahead the backend views and design principles of Symphony are most certainly a head start! Using this would allow for a time to be allocated to planning an underlying framework structure. There is a system in this proposal which many would like to use. I would much rather just use it than create it, I am not proposing this just for fun.

I am still keen to know, if such a project would be an acceptable use of Symphony Assets and IP to scope this proposal.

p.s. I am not proposing that Symphony branding or name be used for such an experiment.

But I'd question why.

I guess it could be interesting for really high traffic environments because of the async approach with closures (lots of buzzwords here, don't really know what I'm talking about) and therefore more efficient use of hardware resources.

@jensscherbl for sure!

Plus it is an application... the (near) entire Symphony PHP script is run with each request to index.php (ignoring any cache extensions of course which help make the executed php shorter).

It is a script language as much as PHP.

PHP sucks as well :) But it is more mature than javascript in regard to back-end development.

This is an interesting idea, but I don't think it'd be worth anyone's time really, unless you were just using it as a way to learn nodejs; there are easier ways to learn though! Your best bet, if you really wanted to leverage javascript with symphony, would be to use one of the many js-based client MVC-style frontends (backbonejs, batmanjs, knockoutjs, knockbackjs, emberjs) in combination with the REST extension. Symphony would perform better since it wasn't constantly transforming views, only producing data.

I've used all of the 5 I've mentioned (and there are others), I personally prefer batmanjs since it's the quickest to get going. If you're familar with iOS/Mac development emberjs would be the way to go. Backbone is the most basic of them where you'll have to code quite a bit to do simple tasks.

A list of all of them: http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/

you really wanted to leverage javascript with symphony

The goal is not to use javascript with with symphony. I have extensive experience with these libraries but the purpose here is not facilitate Client/Server data modelling and sharing.

The PHP vs. JavaScript is not really too interesting a discussion (certainly not on a Symphony forum) the purpose of the question was more if the visual design, HTML markup, and some other principles and concepts can be legitimately used on another project. And it seems apt to ask such a question on Symphony's forum first.

the purpose of the question was more if the visual design, HTML markup, and some other principles and concepts can be legitimately used on another project

Symphony's licence basically says "please take it and do whatever you want".

And it's the MIT License.

But Symphony's license also states that the license must stay with the code, so the copyright would also need to be present.

I understand that the license says all code can be used, and it's a good thing being open source, but to just lift all of the hard work from one open source community in respect of visual style and workflow, and re-use it for another is a little off in my opinion. We've all put in a lot of hard work on this project, and for someone to just come along and take a shortcut by lifting large chunks of code would anger me a little.

I'm so tired of all this hype about whatever.js :)

I think it's more wise to concentrate the development efforts into a product that can be run on most hosts, instead of a product that need a VPS to run.

I agree with Nick re: 'because' might not be the most productive reason, but of course you'd learn a lot.

More generally, my impression is that app development in Node (and yes while it's probably just as much a fad as RoR, that's not enough of a reason to discount it) is headed toward a more decoupled paradigm of independent modules, rather than the more conventional monolithic CMS such as Symphony.

Personally, if you've got a js itch, I'd be more interested in seeing just how closely Symphony can dovetail with Backbone.js, perhaps autogenerating backbone models, etc. in the manner of Phreeze.

Thanks all for you comments.

still can't wrap my head around why you want to do this. LAMP is the most spread setup you can find and symphony is targeting it. So why make life miserable with more expensive infrastructure and lots of time porting something which is already perfectly fine?

However, how about also making one for Go? :)

Whether or not one values Node.js is beside the point really... if you prefer to develop in Javascript than PHP, it is worthwhile using. Much as if you prefer Python you would probably prefer using Django.

The VPS and LAMP problem is not one I have (its not 2005). We are a doing a large amount of creative development where the server side application layer is as important if not more than the content/data administration layer (symphony/cms). Here there is an advantage to integrating the two.

I love symphony and have gained tremendously from it. But I feel innovation around PHP is not that of Node.js... both are scripted languages. I am using the C++ V8 layer of node in some installation projects, and I know it well. I can't imagine using a PHP abstraction for I/O and fast prototyping. If you find that node is fad, that is cool, I understand. Each to their own.

I guess no-one is interested in this as a potential project/collaboration. No worries, nice to get a sense of what the community thinks. My impression is the Symphony community would not be happy with this... I am barking up the wrong tree! : )

My impression is the Symphony community would not be happy with this...

I don't think the community would have any problems with you going ahead. Symphony CMS is licensed under the MIT license, and my understanding is you're entirely free to incorporate its assets. You could give credit to the project and its authors.

I don't think the community would have any problems with you going ahead. Symphony CMS is licensed under the MIT license, and my understanding is you're entirely free to incorporate its assets. You could give credit to the project and its authors.

I am Allen Chang, and I approve this message.

Okay seriously, I think it's good that Ross has the passion to take the principle philosophies of Symphony and apply it on a different infrastructure. If you want to do this Ross, you have my support.

Progress should be a decree of any software and certainly for open source projects. I think good can come of more people experimenting with taking Symphony into new territories (hell, port it to JAVA and use SAXON).

I think the only concern the community may have is potentially splitting the community's effort across two codebases. Symphony's community is quite small compared to the many open source power-houses today, and contributors (being the most valuable asset any open source projects can have) are few and rare.

We saw this became an issue with Symphony 3.0 (the version reboot we tried to introduce a couple years ago) and ultimately, even if there were many advances 3.0 offered, we had to put it aside so we can continue our ongoing efforts with the 2.0 codebase and keep our contribution efforts unified.

Ross, if you happen to find a way to open the opportunity for the node.js work to somehow benefit the current 2.3.x codebase, I think people will be more receptive and maybe even encouraged to help.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details