Symphony.

@Nitriques, have you seen Mobile Device Detection? It offers both XML and redirection.

@touchstone, thanks - looks good for when you need to detect desktop browsers, too.

@touchstone: This is super nice... I would love to build on this...

Anybody has anything to say about how implementing a mobile version ?

@DavidOliver: No, did not came across this... God do I search wrong sometimes... I searched for 'Mobile Template' and 'Mobile' only an did not came across this....

The problem with redirection is that your have to duplicate your admin environment, i.e. one for normal version and one for mobile one. I am looking for a way to do this only by changing which xsl template gets called for a particular URL. A couple of extension offers rock solid UA detection but none offers a clever way to do alternate templating.

@nitriques Could you not use something like the extension I just wrote to determine if it's mobile and what device it is, and then just have a different style sheet in place?

Or am I way off and shouldn't butt into a conversation half way :p

@Nitirques, the ninja domain technique would allow you to use same admin for both domains though, would it no?

@Nitriques, Could you not use the Mobile Detection extension to do this? It outputs XML to your page (when you assign the datasource to your page), and in your XSLT template I expect you could call different XSLT stylesheets depending on the XML output.

I've been thinking about this for a while, the ability to represent a page in different formats. Other frameworks such as Rails and Zend have respond to helpers, so that you can specify a format (none or .html as the default, .xml, .json, .mp for mobile etc) for the same route but a different view is chosen. Symphony could work in the same way with simple naming conventions:

• page-name.xsl
• page-name.xml.xsl (MIME automatically set to text/xml)
• page-name.rdf.xsl
• page-name.json.xsl

And so on. The implementation is tricky. Some prefer being explicit and putting the extension onto the end of the URL (/page-name.json) whereas others prefer true "content negotiation" so that one single URL is always used (/page-name) but the format is switched depending on attributes of the client (user agent for mobile detection, Accepts header for RDF clients etc).

It needs more thought, but the Content Type Mappings gets close. The Working Groups brought this up in our recent roadmap chat for Symphony 2.3, so it's on the radar as being something that people are interested in...

Hooooooo... some much responses.... Thank you for all your replies!

@nickdunn: Again, you rock man. True negotiation based on the device AND alternative format AND alternative views... Those three features all shared common tasks and goals but are different and may all be useful in different situations. I will stay tune for Sym 2.3 for that.

As for right now, I would like to be able to implement nice way to do the 'template routing'. The solutions provided by @touchstone, @moonoo2 and @DavidOliver are close to what I want, but DON'T want to touch the existing xsl. This would be to much maintenance, as the only thing we would need is:

• Tag which page can have a mobile view
• Preferences to configure how the mobile view gets called

That's it. @nickdunn: Is their a way to change which xsl gets called via an extension ?

BTW I have a client that require a mobile version of their site, so this is something I WILL implement in the next weeks. If you have the time, any help will be appreciated.

That's it. @nickdunn: Is their a way to change which xsl gets called via an extension ?

From the docs it looks like the FrontendPageResolved delegate might provide this information:

$pagedata arrayAn associative array of page data, which is a combination from sympages and the path of the page on the filesystem. Passed by reference

If you can modify "the path of the page on the filesystem" then I presume that is the path to the XSL file.

Kind of related, but I created this basic extension for a project a year or two ago. The client wanted RDF representations of some (people) pages. It was too complex at the time to build this directly into Symphony, so the client preferred to upload these files by hand via FTP, giving them ultimate control over the file contents. The extension checks whether the client's Accepts header stipulates application/rdf+xml, and if an RDF file matching the URL exists then it is served, otherwise the Symphony page is served. A manual override also finds the RDF file by appending .rdf to the end of the URL, for clients not sending an expected Accepts header.

It's hacky, but the concept is similar to what we're discussing.

Excuse me if this is not the appropriate place but I keep coming back to the issue of 'Extension Overgrowth'…

• There's quite a few similar extensions doing (almost) the same thing
• There's popular maintained extensions and deprecated ones
• There's the issue with Extension Compatibility and versioning

Obviously there are different solutions to a problem (e.g. multilanguage) and Symphony does not force a single solution, which is great.

At the moment, however, it's too difficult to find the best extension for a needed task iMHO.

Part of the problem, I believe, is the sub-optimal Search functionality in this Forum and the Downloads/Extensions section of this site. Other issues are the 'categories' of Extensions (too coarse IMHO to be really valuable) and the lack of Extension 'gardening'.

I realize these are difficult issues to tackle, mainly because of the nature of Symphony, but there might be some simple things that we can do to improve the task of finding the best extension for our needs. I've offered before that maybe the (currently hardly used) Featured Extensions section might be useful? We could also add tags or a simple rating system to Extensions. Another thing would be to (automatically) 'garden' Extensions (better): remove or archive deprecated extensions or, in some way, mark them (e.g. 'Core', 'Favourite', or 'Deprecated').

Anyway, what helped me when I just started looking into Symphony were the lists of people's favourite extensions: this provided me with an idea of where to start looking plus gave me an idea of what extensions were already available. How often do Symphonians reply "There's an extension for that!" in the Forums? How often are people asking "What extension do you use to do foo?"… How often does someone publish an extension only to find out there exists one already? IMHO this indicates a current issue with finding (good) Extensions. You need to be fairly active in the forums to have an idea of the current state of extension…

Improving this situation would greatly benefit newcomers in picking up Symphony, would save active Symphonians from writing 'old' forum replies (helping newcomers on their way) and would save developers doing some unnecessary work…

I would love to hear your thoughts on this: do you see it as a problem? And, if so, how do you think we could tackle it?

PS: if this post needs to be in a different thread or warrants a topic of itself… Symphony admins: please make it so :)

I really like the idea of 'Featured extensions' @davidhund! I thought there already was tagging on extensions, although done by the developer, not the user.

Ratings I'm not sure about, one person's extension may solve their problem, but not someone else's. I'd hate for someone to mark an extension 'one star' because it didn't solve their problem, but it really was just the wrong extension for the job.

@Brendo yeah: the Featured Extensions exist, but to me it's completely unclear why these extensions are featured thus rendering the featured category all but useless.

I can't see extension tags, only categories but these are, I believe, too coarse. For example: say I need an extension that automatically resizes images upon upload. Currently I would need to add such an extension to almost all categories: "Field Types", "Interface", "Multimedia" and "Workflow".

This results in a filter/search problem: too many results in 1 category :) When the developer would have tagged the extension with "image" "upload" and "resize" etm. I would have been able to limit the results by filtering on multiple(!) tags…

Good points re: ratings. Maybe something such as "I use this" (erm: "Like!" or "+1" :) ) would be better than a rating. Thanks for your thoughts…

Who is curating this? http://getsymphony.com/download/extensions/featured/

Heh, I have no idea, I didn't even know it existed!

Ah, you are correct @davidhund, I must of been getting confused with categories. I think tagging is a neat idea, and would help address your scenario. I wonder if the Extension search on this site is using the Search Index extension?

I have asked Craig to weigh in here because this is indeed being addressed during planning of the new Symphony site. The plan is for an "I use this" action on an extension (hence the Members Claims extension). The issue of compatibility, maintenance and deprecation is also being addressed.

How about something like "recipes" (or some other term that is more in music/symphony theme :) page, where developers can describe project in a few words, list requirements and then list extensions they used? With categories/tags it could be a pretty quick way for new users to find out what they could use. Showcase section could be upgraded for such thing.

Part of the problem, I believe, is the sub-optimal Search functionality in this Forum and the Downloads/Extensions section of this site.

Agreed. Next version of the site will use Nick's forthcoming release of Search Index, which is going to blow your minds.

Other issues are the 'categories' of Extensions (too coarse IMHO to be really valuable) and the lack of Extension 'gardening'.

Agreed. More below...

Who is curating this? http://getsymphony.com/download/extensions/featured/

No one. I think it's been haphazardly added to over time, but it's not actively maintained.

I think tagging is a neat idea

It is, but we have to consider the potential chaos that could result from having a completely open and unregulated tagging system. I think both extremes (a handful of rigid categories and a shitstorm of random misspelled tags) are equally undesirable and useless, so maybe what we need is a broad but curated list of tags from which developers can chose.

The plan is for an "I use this" action on an extension (hence the Members Claims extension)

That's right. One of the most useful things we can show new users is which extensions are used most often by other users.

The issue of compatibility, maintenance and deprecation is also being addressed.

This goes back to the question of 'gardening'... We need to be much more clear about what we expect from developers, and provide them with the tools to make good decisions about what to build, how to maintain it, and so on... It all starts with some very solid guidelines that need to include notes on duplication and deprecation, among other things.

How about something like "recipes"

The goal of the new site is to simplify. I'd rather start by trying to efficiently solve the problem of making extensions findable in themselves. We can see how that goes first.

Next version of the site will use Nick's forthcoming release of Search Index, which is going to blow your minds

Oh, no pressure then.

Thanks for your thoughts/replies. Great to hear most points are being addressed.

The goal of the new site is to simplify. I'd rather start by trying to efficiently solve the problem of making extensions findable in themselves. We can see how that goes first.

Agreed. I have some doubts about the tagging (esp. if the Search would perform better). A simple solution of 'likes' (Member Claims) would already be a great help.

Another simple (automatic) improvement would be to show download counts. For example: both Wordpress and Typo3 show global download counts for a plugin as wel as a download count for a specific plugin version. This information is basically an automatic implementation of 'likes'. The problem, of course, is that this data is not available: extensions are mostly hosted on Github :/