Symphony.

I agree - this is an absolute showstopper for dynamic options. I'll make sure we fix this ...

OK, I get the idea. Sounds great.

Another 2+ months of development? This is a long time for you (working) and for us (waiting), but I am sure that Symphony 2.0 will be worth it.

XPath expressions in data source filters

One question concerning data source filtering: will it be possible to use something like {not(/data/section/entry/@handle)}?

Considering the estimated development time, I believe that a complete rewrite from the code (building towards the set out genius functionality and GUI - the essence of symphony) using a zend as a php framework, plus a DB layer, would have many advantages, and can be achieved in the same timespan; User management, dom xml, these are all readily available. And there is a huge community. Have a look at Magento(and there use of xml) and see how well they fare by tapping into zend. (porting)extensions, community debugging and improvement, would all greatly benifit. Now that you've gone open source, I see no argument in keeping away from frameworks (same goes for javascript) I know they are updated regularly, but that is evolution, and 'a good thing'.

Or are you already down this road, and is the estimated long development time based on the initial learning curve of zend?

Once our beloved symphony gets more attention, I see it quite possible that someone (with large community- and or corporate-dynamics) would 'borrow' the genius functionality of symphony and poor it into his own system, based on a framework, rapidly developed and dynamically marketed, becoming the new standard and taking away the spotlight of Symphony. The Microsoft windows vs Macintosh classic OS scenario. This would be a shame.

Has this been considered, is there a long term strategy in place? I'd love to be convinced with good arguments that having no framework for symphony is essential, and that the longer and more complex core code development time would prevent the above scenario. Because its quite useless (when its free and opensource, not when its commercial) to rewrite an application in almost exactly the same way, unless you switch environments or can make it more universal-more popular, or easy to host environment. A nice case-study; hosted basecamp(ror)> free activecollab(php)> payed activecollab > free projectpier(original activecollab php evolution)

One question concerning data source filtering: will it be possible to use something like {not(/data/section/entry/@handle)}?

Nils, have a look at the DS editor screenshot in Allen's presentation. There's a "Filter Method" select box with "Contains All" as the default option. The other options in this select box (for text input fields) are "Contains None", "Contains At Least One", "Lies Within Range" and "Matches Regular Expression". I think the "Contains None" method would be more suited to your needs, since by selecting this, a value of "private, {data/current-entry/entry/@handle}" will filter out entries with field values of "private" and entries with field values whatever {data/current-entry/entry/@handle} evaluates to.

Of course, XPath expressions in DS filters are evaluated as real XPath with all XPath functions available, so your example would actually evaluate to the string value of /data.

Now that you've gone open source, I see no argument in keeping away from frameworks

Hey Jiri, I'll try to give you a better picture of our development process:

We recently gave ourselves 2 months to turn RC1 from a drawing board concept into an actual release, but due to optimistic predictions and/or ambitious goals, we failed to make the deadline.

Very little of this time was spent writing implementation code. The bulk of it was spent writing proof-of-concept demos, spec drafts and performance tests in order to decide what the feature set should be, whether our ideas are even practical and how best to implement them. This is as time-consuming a process as writing the implementation itself, since we need to explore the consequences of any decision to make sure it works logically.

E.g.: Can Symphony programmatically determine order for multiple text formatters, or does the user have to specify this? Are "Filter Method" parsing modes really a better alternative to the DS syntax rules in rev-5? How should entry reordering work in conjunction with pagination or sorting by field?

There are countless decisions like this that have a real impact on how coherent, useful and stable Symphony is. Writing implementation code is trivial compared to this, and it is not what we spend the majority of our time on.

I agree with your list of benefits of using frameworks, but since the Symphony core is so small and specific, I don't think it needs these. Using a framework would add overhead, bulk and raise the minimum requirements, and most undesirably add the possibility of framework-level bugs and maintenance work. These sacrifices don't seem warranted when the core would use <5% of what a framework like Zend has to offer.

Our vision for the Symphony core is for it to be as minimal and lightweight as possible, because it needs to be used by everyone. Extensions are there to provide the extra fancy features, and that's where the use of a framework would pay off more. We don't want the Symphony core to be a constantly ongoing project - we want to gradually shift more of our attention towards building extensions.

Just to clarify, my 2 month estimate is based on the fact that we are currently juggling client projects in between Symphony development. It will mostly consist of coding the implementation, since nearly all of the conceptual work has been finalised.

regardless of when this gets release, i can't wait to try it out (well, i'm going to have to, of course)

Thanks for the insight Scott, I couldn't agree more (and know) that the design is the most important and time consuming. I really like the idea of the core being so minimal (which I forgat for a moment), which brings to mind how cool symphony would be as an extension to other more complex webapps.

A real life scenario; a blog, forum, website and webshop need to be combined. I considered the closest integration for now would be having a symphony install run side by side(like the forum here) with a vanilla one, and a magento one . I kept hoping symphony could one day with the right extensions become all this. But each app has its speciality and community keeping it in line with market needs. Even if symphony could offer magento's features, it would still need the community, training and thriving business model behind it in order to replace it. So why not adding symphony and vanilla as magento extensions... Making symphony something like the markdown of webapps; the essential extension for unlimited CMS options.

What do you think about this?

What do you think about this?

I think this would be too much: keep it smart and simple ...

Nils, my idea was to keep it small and simple.

And then to have symphony as an extension to smart and complex webapps that miss the universall CMS features.

For those who need a webshop with the latest plugins into their workflow magento is a beter choice then symphony with extensions. Yet for the content part of their site, symphony is still a very good candidate. Would you suggest to install them side by side (on a subdomain or something) without integration of symphony content on the shop frontpage...

I think Symphony does 2 essential things very well: provides an interface for modeling internal data, and allows for more or less unlimited flexibility in producing views of any xml-accessible data through its use of xsl.

While I agree that working with a framework would probably make extensions alot easier, all of Scott's points seem perfectly valid to me. Looking beyond internal Symphony extensions, though, I see (by virtue of the two capabilities above) Symphony as the perfect platform to integrate web services/applications from anywhere, not just within a Symphony install. As I see it that's the long view that makes Symphony a winner. The sooner extensions are produced to enhance Symphony's capability in this regard the better IMHO.

I find the notion of Symphony as an extension difficult. I don't see that ever happening.

While I agree with ashooner, in reality using Symphony as a bridge and view on different webapplications only works best if the client is not needed in the backend (no input directly). Its not nice for the client to jugle 3 or more different backends.

I totally digg symphony being universal, but this is only to a certain extent. Because there are always webapps better at specific tasks (or shoudn't this be the case...*) When you promise a client ultimate extendability, only to tell him later a magento install needs to be added for his webshop (learning new backend) you just made a false promise.

*To truly rock symphony must at least offer extensions that offer (limited minimal , basic, OK: like textpattern vs wordpress) webshop, forum, CRM possibilities. This might not be so hard to offer as it seems, and you can take a cue (or even port) from the more complex applications out there.

Started a new thread for the more abstract prognostications about Symphony.

I feel I disagree with newnomad on the definition of what Symphony is and what it should be. Symphony is at its core a content management system. It looks like it is going to have user role management, but is primary aim is to facilitate the management of content on web sites. You can build web applications with Symphony, and RC1 is going to make this easier; but I certainly don't think Symphony should become an application management system (AMS?!).

If Vanilla and Magento and the like offer some form of RPC/REST interface, as Symphony's Events do, then you could potentially write extensions which connect the applications together. For example a Magento shop may provide a list of products as an XML feed that can be imported into Symphony as an external XML data source. You could write an extension to provide functionality to view and modify this data through the Symphony backend (thereby keeping the consistent UI).

But I don't believe Symphony should have this functionality out of the box. It should provide us with an array of tools for defining, publishing and consuming content; which we use to solve problems.

One developer may need to build an extension that pulls images from Flickr and allows users to moderate them before they go onto a website. Another may need to integrate with a CRMS, making SOAP calls when creating or saving an entry. Another may need to build a multi-user blog. Another may just want a 3-page content-managed website. With a "smart and simple" core (and an intuitive way of writing extensions), all of these would be possible.

I agree with nickdunn.

Guys we should continue this at the new thread ashooner made. While we can only inspire(or provoke ;-) the team, symphonies future is their call, and I would like to hear it from them. If keeping it minimal is the route, I'd even consider positioning it as a feed to website app only (the tap on the yahoo pipes, so to speak), forget about backend data entry (sections), and go all googleapps for content....

I agree with newnomad.

Ok, is there anyway we can view this video on the iPhone 3G? I have some time away from the office and I would love to digest the presentation video on my iPhone. Can it be done?

Hope Allen doesn't mind, but I converted it quickly to iphone format and uploaded it. You might have to right click and download otherwise it may start streaming instead.

http://creativeflux.co.uk/videos/s2-presentation-r2-iphone.m4v

Hey Dru,

Good work. Now all you need is the iPhone. :)