New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: use XSL for fields and content pages in the admin #1463

Closed
kanduvisla opened this Issue Sep 26, 2012 · 22 comments

Comments

Projects
None yet
9 participants
@kanduvisla
Contributor

kanduvisla commented Sep 26, 2012

I've created some extensions now, and I'm always wondering why the creation of HTML in the backend needs to be so complex. Why can't the HTML of the backend not be rendered with XSL just like the frontend? Take this code for example to create a simple input-field on the publish page:

$label->appendChild(
    Widget::Input('fields'.$fieldnamePrefix.'['.$this->get('element_name').']'.$fieldnamePostfix,
        (strlen($value) != 0 ? $value : NULL)
    )
);

Although shorter, the big problem with this is that it doesn't seperate code from output, and it's harder to understand, difficulter to read, and raising the bar for new developers wanting to create extensions.

The use of XSL can easily be implemented with a little function like:

private function parseXSL($xsl, $xml)
{
    $xslt = new XSLTProcessor();
    $xslt->importStylesheet(new  SimpleXMLElement($xsl));
    return $xslt->transformToXml(new SimpleXMLElement($xml));
}

On the publish page, the generation of the HTML could easily be done with XSL for the presentation, and XML for the variables:

$xml = new XMLElement('data');
$xml->appendChild(new XMLElement('field', null, array(
    'name' => 'fields'.$fieldnamePrefix.'['.$this->get('element_name').']'.$fieldnamePostfix,
    'value'=> $value
)));

// Create a div with the content of the parsed XSL file:
$label->appendChild(
    new XMLElement(\'div\', $this->parseXSL(
            file_get_contents(EXTENSIONS.\'/'.$vars['FOLDER_NAME'].'/fields/publish.xsl\'),
            $xml->generate()
        )
    )
);

The XSL Could simply look like:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output omit-xml-declaration="yes" />
    <xsl:template match="/">
        <input type="text" name="{data/field/@name}" value="{data/field/@value}" />
    </xsl:template>
</xsl:stylesheet>

Now, this might look more complex, than the first example, but imagine a more complex field, like the Google Maps field, or SelectBoxLink+ or SubSection Manager. The steps of the field then always are very easy:

  1. Create an XML with all the data
  2. Parse an XSL file

And this is just for fields. The same could be applied for preferences and content pages! It makes the whole authoring process of extensions a whole lot easier.

And although this is already possible at the moment (I'm already aiming at making my extensions as much as possible in this format), it's not a method that is widely performed/promoted by the community.

What are the thoughts of the community on this? It would imply that the way the backend is rendered at the moment to be diversed in PHP-files for code execution and XSL for presentation, but on the longer term it makes the code easier understandable and manageable in my opinion.

(On a small sidenote: I'm also promoting this type of extension programming in my Extension Developer utility)

@nickdunn

This comment has been minimized.

Show comment
Hide comment
@nickdunn

nickdunn Sep 26, 2012

Contributor

There are already a few extensions that create their backend pages using XSLT (@creativedutchmen?) and Symphony should totally be doing this. In theory ;-)

Contributor

nickdunn commented Sep 26, 2012

There are already a few extensions that create their backend pages using XSLT (@creativedutchmen?) and Symphony should totally be doing this. In theory ;-)

@kanduvisla

This comment has been minimized.

Show comment
Hide comment
@kanduvisla

kanduvisla Sep 26, 2012

Contributor

@nickdunn: I know! So more developers have seen the light! This type of programming should be more promoted by Symphony. For example by it's core fields, content pages and preferences. I know this is a lot of work and with almost zero visual result, but at least it should be a blip on the radar for upcoming functionality.

Contributor

kanduvisla commented Sep 26, 2012

@nickdunn: I know! So more developers have seen the light! This type of programming should be more promoted by Symphony. For example by it's core fields, content pages and preferences. I know this is a lot of work and with almost zero visual result, but at least it should be a blip on the radar for upcoming functionality.

@designermonkey

This comment has been minimized.

Show comment
Hide comment
@designermonkey

designermonkey Sep 26, 2012

Member

Yes.

It is on the cards, but the current mahoosive issue list takes priority. We have so many feature requests and already a big list for 2.4

It's been on the wish-list for at least 2 years if I remember right, so it will happen. To make it happen though, we need more developer support for the core, as we have few people who have little time.

Member

designermonkey commented Sep 26, 2012

Yes.

It is on the cards, but the current mahoosive issue list takes priority. We have so many feature requests and already a big list for 2.4

It's been on the wish-list for at least 2 years if I remember right, so it will happen. To make it happen though, we need more developer support for the core, as we have few people who have little time.

@kanduvisla

This comment has been minimized.

Show comment
Hide comment
@kanduvisla

kanduvisla Sep 26, 2012

Contributor

I support the core! But also... have little time... :-(

Contributor

kanduvisla commented Sep 26, 2012

I support the core! But also... have little time... :-(

@designermonkey

This comment has been minimized.

Show comment
Hide comment
@designermonkey

designermonkey Sep 26, 2012

Member

Same here.

Member

designermonkey commented Sep 26, 2012

Same here.

@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Sep 26, 2012

Member

How would you handle localisation of the backend in your XSL templates for the backend?

Member

nilshoerrmann commented Sep 26, 2012

How would you handle localisation of the backend in your XSL templates for the backend?

@creativedutchmen

This comment has been minimized.

Show comment
Hide comment
@creativedutchmen

creativedutchmen Sep 26, 2012

Member

@nilshoerrmann I think the best way is for PHP to read the localised strings, and put them in the XML. One small utility can then provide the correct strings based on the system locale.

For everybody else: I think the approach we could follow is very simple; we just need to change the functions to return XML rather than HTML. This is pretty straightforward, since all functions for this already in place (array_to_xml, to name one). Then a naming scheme for the template files (just like we have for pages) is enough for the whole thing to come together.

I'll be having a bit of spare time to tinker with this the coming month, would you like me to whip out a proof of concept of how this could work?

Member

creativedutchmen commented Sep 26, 2012

@nilshoerrmann I think the best way is for PHP to read the localised strings, and put them in the XML. One small utility can then provide the correct strings based on the system locale.

For everybody else: I think the approach we could follow is very simple; we just need to change the functions to return XML rather than HTML. This is pretty straightforward, since all functions for this already in place (array_to_xml, to name one). Then a naming scheme for the template files (just like we have for pages) is enough for the whole thing to come together.

I'll be having a bit of spare time to tinker with this the coming month, would you like me to whip out a proof of concept of how this could work?

@nickdunn

This comment has been minimized.

Show comment
Hide comment
@nickdunn

nickdunn Sep 26, 2012

Contributor

One idea I had is that the section listings tables essentially become XSL pages that can consume data sources. Symphony would create a data source on the fly to render these. Pagination done using the pagination utility, and so on. It requires a fairly comprehensive rethink of how fields render themselves — perhaps each one provides its own XSLT file with a template that matches its own name, which is included to render the HTML on the publish page? This means all methods that currently return HTML should return XML. Or are you suggesting continuing returning HTML (for now) and Symphony does a copy-of to get them into the page?

Contributor

nickdunn commented Sep 26, 2012

One idea I had is that the section listings tables essentially become XSL pages that can consume data sources. Symphony would create a data source on the fly to render these. Pagination done using the pagination utility, and so on. It requires a fairly comprehensive rethink of how fields render themselves — perhaps each one provides its own XSLT file with a template that matches its own name, which is included to render the HTML on the publish page? This means all methods that currently return HTML should return XML. Or are you suggesting continuing returning HTML (for now) and Symphony does a copy-of to get them into the page?

@kanduvisla

This comment has been minimized.

Show comment
Hide comment
@kanduvisla

kanduvisla Sep 26, 2012

Contributor

@nickdunn: what you are saying is absolutely correct. I even think that the backend can be pushed as far as being rendered/build the same way the frontend does (based on datasources and events etc.). To create a proof of concept of this, one should rebuild the Symphony backend as a website in the frontend (workspace) using datasources and events. It would be interesting to see if (and how far) this could be achieved. Because then the same render engine is used for frontend and backend, making the system much more transparent to work with than it is now.

The main gotcha for this are indeed the dynamic components that should be included in the output. Perhaps a field rendering its own HTML and simple copy-of could do the trick.

<!-- Render all fields in the publish/edit page on the main location: -->
<xsl:for-each select="section/fields[location='main']">
    <div class="field field-{name/@handle}">
        <xsl:copy-of select="html" />
    </div>
</xsl:for-each>

This opens also a window of opportunities, for example for extensions to create different kind of publish-index-pages. Something that has been on my list for a while too!

Contributor

kanduvisla commented Sep 26, 2012

@nickdunn: what you are saying is absolutely correct. I even think that the backend can be pushed as far as being rendered/build the same way the frontend does (based on datasources and events etc.). To create a proof of concept of this, one should rebuild the Symphony backend as a website in the frontend (workspace) using datasources and events. It would be interesting to see if (and how far) this could be achieved. Because then the same render engine is used for frontend and backend, making the system much more transparent to work with than it is now.

The main gotcha for this are indeed the dynamic components that should be included in the output. Perhaps a field rendering its own HTML and simple copy-of could do the trick.

<!-- Render all fields in the publish/edit page on the main location: -->
<xsl:for-each select="section/fields[location='main']">
    <div class="field field-{name/@handle}">
        <xsl:copy-of select="html" />
    </div>
</xsl:for-each>

This opens also a window of opportunities, for example for extensions to create different kind of publish-index-pages. Something that has been on my list for a while too!

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Sep 26, 2012

Member

We shouldn't forget: When it comes to datasources and events, the templating layer can become rather complex (because of different field types and somehow "special" datasource and event XML). I already have re-built parts of the Symphony backend to allow authors (which are members in this case) to manage content using a dedicated frontend administration area, so I know that it would be a big task.

On the other hand I am a big fan of this idea. If Symphony could do this, it would as well be much easier to build custom frontends (using existing backend code).

BTW, I just talked to @brendo yesterday about this. :-)

Member

michael-e commented Sep 26, 2012

We shouldn't forget: When it comes to datasources and events, the templating layer can become rather complex (because of different field types and somehow "special" datasource and event XML). I already have re-built parts of the Symphony backend to allow authors (which are members in this case) to manage content using a dedicated frontend administration area, so I know that it would be a big task.

On the other hand I am a big fan of this idea. If Symphony could do this, it would as well be much easier to build custom frontends (using existing backend code).

BTW, I just talked to @brendo yesterday about this. :-)

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Sep 27, 2012

Member

Experimentation is fun, but please don't recommend this as "the way" to do things with the builder extension. It may be misleading to new users. Neat experiment though!

Member

brendo commented Sep 27, 2012

Experimentation is fun, but please don't recommend this as "the way" to do things with the builder extension. It may be misleading to new users. Neat experiment though!

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Sep 27, 2012

Member

Fair enough. As long as Symphony does not change the way backend pages are built, we shouldn't promote the usage of XSLT (in this area) too much either.

Member

michael-e commented Sep 27, 2012

Fair enough. As long as Symphony does not change the way backend pages are built, we shouldn't promote the usage of XSLT (in this area) too much either.

@kanduvisla

This comment has been minimized.

Show comment
Hide comment
@kanduvisla

kanduvisla Sep 27, 2012

Contributor

Soooo... to wrap it up:

We keep it for now as an exotic little trick that makes extension development easier, but as long as Symphonys' core doesn't implement the same mechanism of backend-page-building, it's not promoted, although this might change in the future.

Does that sum it up correctly?

Contributor

kanduvisla commented Sep 27, 2012

Soooo... to wrap it up:

We keep it for now as an exotic little trick that makes extension development easier, but as long as Symphonys' core doesn't implement the same mechanism of backend-page-building, it's not promoted, although this might change in the future.

Does that sum it up correctly?

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Sep 27, 2012

Member

Well, yes, I think so.

Member

michael-e commented Sep 27, 2012

Well, yes, I think so.

@lewiswharf

This comment has been minimized.

Show comment
Hide comment
@lewiswharf

lewiswharf Sep 27, 2012

Member

I really support this suggestion and remember it has been on Allen's wish List for quite some time

Member

lewiswharf commented Sep 27, 2012

I really support this suggestion and remember it has been on Allen's wish List for quite some time

@bauhouse

This comment has been minimized.

Show comment
Hide comment
@bauhouse

bauhouse Sep 27, 2012

Member

This is probably the feature in Symphony 3.0 beta that I was looking forward to most. If it's a matter of finding help to build out the pages, I have some experience building the Symphony admin with Symphony and would be happy to commit my time to the effort.

I also worked on building templates for a client project that automatically build out views for creating, listing and editing entries with a combination of Section Schemas and Form Controls. I was hoping to document and repurpose the work for the Symphony admin.

Member

bauhouse commented Sep 27, 2012

This is probably the feature in Symphony 3.0 beta that I was looking forward to most. If it's a matter of finding help to build out the pages, I have some experience building the Symphony admin with Symphony and would be happy to commit my time to the effort.

I also worked on building templates for a client project that automatically build out views for creating, listing and editing entries with a combination of Section Schemas and Form Controls. I was hoping to document and repurpose the work for the Symphony admin.

@lewiswharf

This comment has been minimized.

Show comment
Hide comment
@lewiswharf

lewiswharf Sep 27, 2012

Member

I have some experience building the Symphony admin with Symphony and would be happy to commit my time to the effort.

I was just thinking of you Stephen and was about to edit my comment above. I think you have the most experience with this specifically. What you've already done and attempted should be built upon.

Member

lewiswharf commented Sep 27, 2012

I have some experience building the Symphony admin with Symphony and would be happy to commit my time to the effort.

I was just thinking of you Stephen and was about to edit my comment above. I think you have the most experience with this specifically. What you've already done and attempted should be built upon.

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Sep 27, 2012

Member

I suggest to think twice before you put any work into this. As I already mentioned, in my eyes the templating layer is a crucial part of the whole idea. I really like form controls (e.g. for being rather "complete" when it comes to different types of fields), but it is limited in terms of extensibility and flexibility. For one of my projects I have built a different XSLT form layer, but this one is incomplete and must be refactored at some point as well.

Member

michael-e commented Sep 27, 2012

I suggest to think twice before you put any work into this. As I already mentioned, in my eyes the templating layer is a crucial part of the whole idea. I really like form controls (e.g. for being rather "complete" when it comes to different types of fields), but it is limited in terms of extensibility and flexibility. For one of my projects I have built a different XSLT form layer, but this one is incomplete and must be refactored at some point as well.

@bauhouse

This comment has been minimized.

Show comment
Hide comment
@bauhouse

bauhouse Sep 27, 2012

Member

I agree that it would be a lot of work. And Form Controls definitely does have some limitations. It works great for the fields that are accounted for, but if you need anything outside of those limitations, it's not possible to automate the process.

So, it may be best to just putter away at the possibilities over the long term, but not to count on something like this being integrated into the core any time soon. I would, however, like to explore the possibilities.

I have been wondering whether it would be worth trying to extending Form Controls to be able to handle more fields. Or whether extensions that provide new fields would be packaged with XSLT to manage the rendering of the fields.

I was able to build an entire CRUD interface by setting a couple variables in a page template like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:import href="../utilities/section-manager.xsl"/>

<!-- Define a global variable for the section data -->
<xsl:variable name="section-data" select="/data/schools/entry"/>
<!-- Define a global variable for the event action -->
<xsl:variable name="event-action" select="'save-school'"/>

<xsl:template match="data">
    <xsl:call-template name="section-entries"/>
</xsl:template>

</xsl:stylesheet>

If I updated a section in the Symphony admin, the change was immediately reflected in the frontend as the Section Schema data source is parsed to rebuild the interface.

At the very least, I'll document what I came up and release an ensemble as a demo and see if there is a future for the concept.

Member

bauhouse commented Sep 27, 2012

I agree that it would be a lot of work. And Form Controls definitely does have some limitations. It works great for the fields that are accounted for, but if you need anything outside of those limitations, it's not possible to automate the process.

So, it may be best to just putter away at the possibilities over the long term, but not to count on something like this being integrated into the core any time soon. I would, however, like to explore the possibilities.

I have been wondering whether it would be worth trying to extending Form Controls to be able to handle more fields. Or whether extensions that provide new fields would be packaged with XSLT to manage the rendering of the fields.

I was able to build an entire CRUD interface by setting a couple variables in a page template like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:import href="../utilities/section-manager.xsl"/>

<!-- Define a global variable for the section data -->
<xsl:variable name="section-data" select="/data/schools/entry"/>
<!-- Define a global variable for the event action -->
<xsl:variable name="event-action" select="'save-school'"/>

<xsl:template match="data">
    <xsl:call-template name="section-entries"/>
</xsl:template>

</xsl:stylesheet>

If I updated a section in the Symphony admin, the change was immediately reflected in the frontend as the Section Schema data source is parsed to rebuild the interface.

At the very least, I'll document what I came up and release an ensemble as a demo and see if there is a future for the concept.

@nilshoerrmann

This comment has been minimized.

Show comment
Hide comment
@nilshoerrmann

nilshoerrmann Feb 13, 2013

Member

Are we actively working on this or is this just an idea to keep in mind?

Member

nilshoerrmann commented Feb 13, 2013

Are we actively working on this or is this just an idea to keep in mind?

@designermonkey

This comment has been minimized.

Show comment
Hide comment
@designermonkey

designermonkey Feb 13, 2013

Member

This is quite a way off, but needs leaving open. I don't think anyone is actively working on it though.

Member

designermonkey commented Feb 13, 2013

This is quite a way off, but needs leaving open. I don't think anyone is actively working on it though.

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo May 6, 2013

Member

Not in scope for Symphony 2, lets keep this in mind for Next, where Symphony should really eat it's own dog food and be built on itself.

Member

brendo commented May 6, 2013

Not in scope for Symphony 2, lets keep this in mind for Next, where Symphony should really eat it's own dog food and be built on itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment