Search

As I said earlier, I am working on a CMS that also uses XSLT as templating engine but the main difference is that it does transformation on the browser, with the exception of the very first visit to the site or when visited by any browser that does not accept cookies. This is just a way to always send HTML to search bots - since they dont accept of use cookies.

One requirement is that you have php 5.2 or better and have PDO and PDO::mysql installed, the rest are just standard php classes like SimpleXML, DOM, SPL stuff

I decided to make source code available from anonymous svn it’s not even a release, it’s sort of like a pre-release for developers to see and try.

Basically lampcms is a spin-off of my earlier attempt to create a good cms. That’s why there may be some code in some classes that is not even used anywhere, it’s just leftover from the old cms that I have not yet ported to the new one.

http://cms.lampcms.com/

If anyone is able to successfully install it or must has problems with installing, email me or post comment right there.

So the xhtml offered to first time visitors and bots is just created serverside? Interesting approach. What do you see as an advantage for clientside transformations? The next point release of symphony would also offer optional clientside transformations. Maybe the team sees the use for intranets? or are there other good reasons to go clientside? To simplify the cms is not realy valid, since you still need transforms for bots. Or do you condsider desktop transforms? maybe this an argument for shared hosts not supporting xsl?

I don’t think it’s a good idea transform the XSLT on browser because this kind of process should not happens on the user’s computer.

In my opinion, browsers are made to read HTML code.

When you transform on browser you have these advantages: payload is much smaller. Basically the browser caches the xsl template, so all repeat visits to the site will only require the download of XML, which is much smaller in size, so less bandwidth is used.

Also for a super busy websites it will offload some processing power to the client. Let the client do at least some of the work. I mean, the server can generate xml very fast, then let the client do the final work of transformation.

I don’t agree that browsers are made to read HTML code. This is just silly. Browsers had XSLT support for over 10 years now. Some are better at it than others, but they all understands XSLT 1.0

Third - I don’t have this implemented yet, but soon I will be able to send different XSL template to mobile browsers. So, I will still be sending exact same XML, just different template for iphone users, so that they will see the site optimized for their smaller screens.

Third - I don’t have this implemented yet, but soon I will be able to send different XSL template to mobile browsers. So, I will still be sending exact same XML, just different template for iphone users, so that they will see the site optimized for their smaller screens.

Sounds good, but actually thats what CSS media=”handheld” is for.

CSS is not able to do what XSL template can. With XSL you can make completely different layout and then the rendered HTML will also have totally different css files in it for the mobile device.

You don’t need a different markup for different layouts. With CSS you can create several completely different layouts on top of one single HTML (thats what CSS is for).

OK, then why do we even need XSL if CSS can do all that?

OK, then why do we even need XSL if CSS can do all that?

So you can send different content to mobile devices. When bandwidth is at a premium sending targeted content to a handheld device makes for a much smoother user experience. The alternative is to send the highest denomination (i.e. the high fidelity web page) and use CSS to conditionally hide portions of it; resulting in higher file sizes.

Why use CSS to hide content using some tricks like visibility = ‘none’ when XSL can just not include the entire portion.

Also, XSL for mobile site can make different ‘src’ attributes of images. For example the XML can have img src=”/myavatar.jpg” then XSL for regular browser will transform it to src=”/web/myavatar.jpg” and XSL for mobile browser will transform it to src=”/tiny/myavatar.jpg”

The same can be done with all images - rewrite the value of src to point to small images.

Other elements can also be transformed totally different.

CSS just cannot do these things

Ok, you may be asking, why not generate different XML for mobile device since not all elements of the XML may be used for mobile devices?

Short answer is because the part of my cms design user an already pre-created static .rss files

So if you go to home page of cms.lampcms.com

(make sure it’s not your first visit), then look at the page source. You will be scratching your head, what the XXXX? Where is all the content?

The first 25 posts are stored in a static .rss file, so visits to home page don’t generate ANY of the database calls, none, nada!

And as a bonus, the same .rss file can be used by any aggregators as a regular site feed. So basically I am using my own site feed to generate a page. This may sound weird but it does make a lot of sense.

Anyway, that’s the reason that I can’t generate different XML for mobile devices - because the XML is already created and lives on the server as a static file. The only thing I can do is to send a different XSL file to that a page is rendered differently on mobile devices.

Im don’t know why you try sell me some CMS. i dont like it. im like symphony. i can sell you my homebake some pizza and you try ok?

I am not selling anything. It’s free. Isy our pizza free? I’ll try it then. I am just looking for input from knowledgeable developers, and I thought this site has good developers hanging around.

phoque:

You don’t need a different markup for different layouts. With CSS you can create several completely different layouts on top of one single HTML (thats what CSS is for).

Sorry, but I’m going to have to call shenanigans on that one. This is the great falcity of the ‘CSS revolution’ of a few years ago. I have to agree with Mr. SMith: If X/HTML is truly semantic, and CSS gives you complete flexibility in layout, then the only XSL you would ever need would be a relatively superfical translation from your semantic XML to html. You can have greatly varied layouts with CSS alone, but for something as different as mobile vs desktop, it can be ideal to have separate markup.

That said, I’m not sure how string clientside XSL is on mobile devices right now.

On the topic of clientside transforms, couldn’t this also very easily be done in Symphony, with all the same benefits (client caching the XSL and JS transformer). I know jQuery has a plugin that uses Google’s AJAXSL.

Indeed beside sbrowser transformations, JS transforms is also, - or even more- a valid option

Closing this one as it’s seriously off topic.

@mr_smith: a gentle reminder that this is Symphony forum…

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