Symphony.

Hello!

Just wondering, since the templating engine is XSLT, have you even thought of sending the XML to the browser and have the browser do all the transformations?

Have you tried it and decided against it or what?

It seems like if you just send XML to browser you can reduce the file size since only the actual content is sent and browsers usually cache the XSL template, so it really only downloaded once and then reused.

I don’t think enough browsers can do it, so you’d be left with a lot of people who couldn’t view your site.

Are you kidding me? ALL browsers make in the past 5 years support XSLT 1.0 (none support XSLT 2.0 right now)

Some browser have had support for XSLT 1.0 for almost 10 years.

As long as you stick to XSLT1.0 (which I think is the case with symphony) you will be fine with all browsers.

The reason I asked is because I also developing the CMS based on XSLT and I chose to go with browser-based transformation. My CMS makes a decision of wheather to send XML or do transformation on the server based on wheather or not a browser accepts cookie (at least a session cookie)

Anyway, my CMS is very new, it will be released as an open source in about 6 weeks. You can have a look at www.lampcms.com

You can register and just browse around using different browsers. my blog there is at http://webmaster.lampcms.com

Many posts in my blog are just made for testing purposes, but some are real posts.

My CMS also has image and image album hosting.

Anyways, I just found this symphony cms yesterday, downloaded it, looked at the code. It looks good, but not enough documentation in the source code.

I was wrong! I guess they do support it. Interesting …

So, why can’t they all seem to support CSS3? >:-(

mr_smiths:

Are you kidding me? ALL browsers make in the past 5 years support XSLT 1.0

But there’s some bugs and differences in implementation, or rather how much they have implemented, isn’t it? The “problem” as I see it is that when leaving the data transformation to the client side you never really know what you’re delivering (or that is taking it to the extreme but you get the point).

As long as the data is delivered to the client as intended the client side styling is secondary. But if the data transformation is handled by the client and something gets messed up…

But I’m with you, I’d love to have client side transformations that I could rely on. I’m not sure if I do right now, but on the other hand I haven’t explored the area too much either.

MrBlank:

So, why can’t they all seem to support CSS3? >:-(

XSLT 1.0 became a W3C recomendation in November 1999, CSS3 isn’t even close to finished.

What bothers me is that there seem to be no way to use XSLT 2.0 with PHP, or is it? Because XSLT 1.0 is really frustrating some times and the amount of code you have to write to accomplish the same stuff as with XSLT 2.0 is just ridiculous.

There are plenty of big sites using client-side transformation (I recall seeing .xml pages being served on sites for IBM and British Airways) so it isn’t beyond the boundaries of possibility to achieve this.

There are however a few downsides:

• While the browser may cache the XSLT, every page tends to have its own XSLT file so there are still two or more files to download for every page. The initial page weight (pre-caching) will be larger.
• Symphony Pages are the “View” part in MVC and therefore often contain conditional logic to define what HTML is rendered to the client. This could be checking whether a user is logged in and showing a comments form, or something altogether more secure. Sending the entire view logic to the browser opens vulnerability to an obvious security exploit. A hacker can see your entire page logic and potentially reverse-engineer it.
• Has there been any work done on render speeds of XSLT transformations on the client? There can already be noticeable performance hits when rendering large portions of HTML (when sent as plain HTML from the server) — adding in the requirement of first building this HTML from XML, and I’m certain render times will increase.
• If you’re making rapid iterations to your site is there a way to force clients to expire their XSLT cache?

I’m not saying client-side transformations are a bad idea, but I think they’d limit what Symphony can do.

Looking forward to seeing how LAMP CMS progresses though — it’s an interesting concept!

It looks good, but not enough documentation in the source code.

We’re working first on the documentation from the “user” perspective (setting up Symphony and using it to build a site). I hope that developer documentation will follow — probably not as code commenting, but more of a class/API reference.

Yes, I’ve seen some problems with client-side transformation. That’s why I asked this question here because I thought that maybe you guys have good reason to not going this route.

Some problems I’ve encountered: Firefox sucks big time because it does not support the disable-output-escaping=”yes”

It’s really funny that there is a support ticket of a Firefox website asking, begging developers to fix it, but they keep refusing, coming up with excuses. The funny part is that this bug is 8-years old!

I’ve made some posts there too, (my name is Dmitri by the way) https://bugzilla.mozilla.org/show_bug.cgi?id=98168

Another big problem is that devices with slow CPU take considerable time to do the transformation, especially if template is somewhat complex.

This is noticable on iphone. Iphone (except for the latest ‘s’ model) has pretty slow CPU, so it’s noticable slow to transform XML. I think this may also be the case with some other mobile devices.

Last problem is that search engine bots don’t support browser based transformation, so XML/XSLT based output will not be indexed by any search engines at all. For most people this is a big problem.

This can be fixed by doing transfmation on the server if search bot is detected.

About expire XSLT cache: not sure what you mean. Do you mean to download the latest XSL template? Browsers do this automatically just like with any other cached object - they check the last modified time of the file and then download a new version of use the old one. Some browser will NOT update cached template during the same session.

Some browsers report XSLT errors better than others. For example IE provides better error messages in your template is bad than Firefox.

check out jeni’s pages, all offered as xml to; example

Of course we’ve thought about it. In fact, we have a working prototype sitting in our local repository.

Have you tried it and decided against it or what?

Currently client side transformation is not quite possible with the current implementation because Symphony passes parameters via function argument.

What bothers me is that there seem to be no way to use XSLT 2.0 with PHP, or is it?

We’ve made a prototype server environment that uses Saxon XSLT 2.0 under the Java environment about a year ago. It is not quite production ready as there are error message passing issues and consistency in performance isn’t quite there yet. Suffice to say, this set-up isn’t possible without a VPS or Dedicated environment and the procedure isn’t particularly easy.

It seems like if you just send XML to browser you can reduce the file size since only the actual content is sent and browsers usually cache the XSL template, so it really only downloaded once and then reused.

As Nick Dunn mentioned, what you gain in processing time saved, you lose in initiating additional HTTP download. The other disadvantages are:

1. Security (especially user login details and POST data return from events)
2. IE’s MSXML was implementing with the draft spec of XSLT 1.0, although since then it has added better support but it’s still not quite XSLT 1.0.

Whilst there is no evident of significant advantage going client side, this is a feature we will be supporting in the next major point release of Symphony.

Security (especially user login details and POST data return from events)

Not sure what do you mean? How is it less secure and what does it have to do with forms?

What does it have to do with login details? If user is logged in, then I just add an xml element like then XSL template knows it can render ‘hello Bill’ If there is any special content that should only be available to Bill, then I send this special content in XML file. It’s not really different from sending different HTML to logged in user.

And I still don’t know how forms are different? By the way, I don’t send the ready-to-use HTML for the form. I send form elements as XML elements and have template render the form, including all input, even adding submit button. Since every form has a submit/reset button, I don’t have to send it in XML at all, just have the XSL add these buttons to the bottom of the form.

Using XSTL 2.0 would be really cool. But setting up an external xslt parser even though possible, is way to difficult for the regular end-user.

What about using apaches mod_xslt2 http://www.mod-xslt2.com/

Does it support XSLT 2 or not?

@mr_smith: take a look at how Symphony works with data source and events.

It is possible for XML to hold that you may want to keep private for certain level of users. Depending on how the data source or event is set-up it could return:

1. User’s real name
2. Email address
3. Login password hash
4. Entry ID (and all associated IDs)

It’s possible to hold even more private data in the XML depending on your environment. With server-side processing, you don’t need to worry about the sensitivity of the XML data since they will not be presented to the client. However, with client-side processing there is this layer of privacy to consider.

And I still don’t know how forms are different?

Forms are not different. But if you want feedback to your post data, you’ll need to send the data back to the XML at some point. For example, you may need to repopulate the comment text area with the user’s comment if the form did not successfully submit.

Forms are not different. But if you want feedback to your post data, you’ll need to send the data back to the XML at some point. For example, you may need to repopulate the comment text area with the user’s comment if the form did not successfully submit.

I already have a comment feature on my site. The form just submits like a regular http post form. Remember that once the browser transformed your XML into HTML, you have a regular html page and it behaves like a regular html page.

If you want to populate the comment form then just send the content as CDATA and have XSL template insert the content into form as form’s value.

Anyway, you can try to register on www.lampcms.com then try to post a blog entry or upload an image. It works like a normal html form.

What about using apaches mod_xslt2 http://www.mod-xslt2.com/

The latest development code was last updated in November 2004. XSLT 2.0 did not come out of draft until January 2007. That would suggest to me that it does not support XSLT 2.0. Even if it does, it would be the draft spec.

I think I understand what you mean by privacy concerns with browser-based transformation. You probably have that logic right in XSL template. Sure, then you can’t use browser-based transformation now. You just need to move that logic somewhere before the XML element is added to XML file.