Generalizing template placeholders (beyond $Layout / $Content)

[Artyom]

Hi all.

I wanted to talk about the possibility of generalizing the $Layout /
$Content mechanism in SSViewer. (Sorry if I've missed an existing
discussion of this...)

I would really love to be able to do something like

Layout/
Content/
Header/
Sidebar/

For larger and more complex site, this could be quite useful. I
experimented just a bit by adding these to the area in SSViewer in
process() ... (line 407 ish in 2.4.3)

Seems to be all that is required.

Any thoughts?

[Hamish Campbell]

I think this would be an excellent feature!

[Artyom]

Yeah.. The change seems pretty simple, since all the real work is done
in ManifestBuilder. All I did was add them manually to that array in
SSViewer::proces()

I was just wanting to inquire if there was some philosophical reason
why that was avoided... like too complex for new users or some other
reason that had to do with module support.

I was envisioning something in _config.php like

SSViewer::addTemplateComponents('Header', 'Sidebar')

On Thu, Dec 16, 2010 at 1:09 PM, Hamish Campbell <HN.Ca...@gmail.com> wrote:
> I think this would be an excellent feature!
>

> --
> You received this message because you are subscribed to the Google Groups
> "SilverStripe Core Development" group.
> To post to this group, send email to silverst...@googlegroups.com.
> To unsubscribe from this group, send email to
> silverstripe-d...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/silverstripe-dev?hl=en.
>

[Uncle Cheese]

Love it!!!

Have you guys also noticed that the Layout directory is not recursive?
On a large site, you can't break up your Layouts in to subfolders, for
instance. Major drag.

[Artyom]

yeah, that would be a change to ManifestBuilder, which basically
assumes one level

[Martin Pales]

Fantastic idea! Actually, it would be great to be able to create any template directory and refer to it by $DirectoryName as in case of $Layout.

+1

Martin

[Artyom]

That is the other option... SSViewer could ask the ManifestBuilder,
"Which ones did you find?" and then it could build a token list from
that. That would be ideal. I agree : - )

[Artyom]

I'd love to hear from some of the SS core dev's about this. It's a
change to the dev model, so I'm sure there are oppinions

[Sam Minnée]

Yeah, I thought I'd let the conversation see where it led for a bit... ;-)

It would definitely be nice to make it easier to arbitrary folders like "Layout" and "Content". I'm not sure if automatically attaching every subdirectory of templates in this way would be the best idea, though, because it might lead to unexpected behaviour - would you expect $Includes to be usable in your template?

The ability to have arbitrary subfolders for organising your templates would also add a little bit of confusion. Would "templates/Layout/MemberPages/MemberSignUp.ss" be rendered to $Layout or $MemberPages? Of course, the easiest resolution here is just to pick a convention and stick with it; my initial thoughts would be that this is rendered to $Layout.

Another alternative is to have a separate template code, for example, <% subtemplate Layout %>, rather than $ layout, and that makes it clear that you're expecting to find a Layout subdirectory. However, this would necessitate a tag like <% if_subtemplate Layout %> or <% if subtemplate Layout %> in order to conditionals around them.

I know that Hamish Friedlander had gone pretty far with a rewrite of the template engine so hopefully that will make it easier to make any necessary changes.

Thanks,
Sam

-------
Sam Minnée | Chief Technology Officer
SilverStripe
http://silverstripe.com

Phone: +64 4 978 7334
Skype: sam.minnee

[Artyom]

Thanks Sam. Just wanted to make sure you all were'nt opposed to the idea. : -)

Here's my vote (which balances the trade offs to my liking)

- subfolders: personally, I don't really see the need, for all by the
very largest of sites. I think the topology of actual page types
would be limited enough and there are other ways to vary content at
that granular a level... I doubt I'd ever miss it.

Having said that, if we feel we need it, I would agree

/Foo/Bar

would only be visible only within a /Foo template and not globally.

-Includes would remain as they are (a special case), but could be
extended to be recursive as well, so /Foo/Includes would contain
includes visible only to a template in /Foo.

Also, if I provided a simple one level extension, would you all
consider it for 2.5? or is this long term only? By this I mean just
an SSViewer::extendTemplates("Header", "Sidebar") which was non
recursive and just added to the current functionality.

Hamish, what about your rewrite? Could it help?

[Uncle Cheese]

Can we hear more details on the rewrite? I didn't know that was going
on. This is exciting! What can we expect?

> >> On Thu, Dec 16, 2010 at 2:10 PM, Artyom <artyom...@gmail.com> wrote:
> >>> That is the other option... SSViewer could ask the ManifestBuilder,
> >>> "Which ones did you find?"  and then it could build a token list from
> >>> that.  That would be ideal.  I agree : - )
>

> >>> On Thu, Dec 16, 2010 at 2:07 PM, Martin Pales <m.pa...@gmail.com> wrote:
> >>>> Fantastic idea! Actually, it would be great to be able to create any
> >>>> template directory and refer to it by $DirectoryName as in case of $Layout.
> >>>> +1
> >>>> Martin

> >>>> On Thu, Dec 16, 2010 at 9:51 PM, Artyom <artyom...@gmail.com> wrote:
>
> >>>>> I wanted to talk about the possibility of generalizing the $Layout /
> >>>>> $Content mechanism in SSViewer.  (Sorry if I've missed an existing
> >>>>> discussion of this...)
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google Groups
> >>>> "SilverStripe Core Development" group.
> >>>> To post to this group, send email to silverst...@googlegroups.com.
> >>>> To unsubscribe from this group, send email to
> >>>> silverstripe-d...@googlegroups.com.
> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/silverstripe-dev?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> >> To post to this group, send email to silverst...@googlegroups.com.
> >> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/silverstripe-dev?hl=en.

[tonyc]

I'm currently using page-elements.com which is based on the 960 grid
system. It allows CMS drag and drop around "Slots" within a "GridPage"
and really seems to supercede the "widget in the sidebar" concept.

I've had a few issues here and there, but it certainly seems to be
working out well.

Any review of generalizing templates should take this module into
consideration.

[Nicolaas Thiemen Francken - Sunny Side Up]

good stuff, the one thing I want to warn for is this "box" like
thinking... For a developer it makes sense, but it can ruin good
designs. That is - one of the best things about SS is that the design
can be anything you want (as long as flash / css / js / html can
concoct it). It needs to stay this way.... Assumptions like
"sidebar", "header", "footer" scare me a bit. I make lots of sites
that mix up all of these.

For the, the biggest hassle with templates is to have to check where
the templates lives (module, theme or theme_module). For large sites,
the includes folder can also get rather messy, and for that
sub-folders may help. For the layout folder I think I would prefer to
keep all page types into one folder.

Another thing for me is that we keep it simple. It is wonderful to be
able to have SS novices (with lots of general front-end experience) be
able to work on the theme folder.

- Nicolaas

[Dan Rye]

Nicolaas, That was my thought at first, however with this idea, current templates don't have to change.  What it allows is having folders, that work like layouts.  You still have layouts, all page types (for layouts) stay in one folder.  However you can add any other folders you want, that also work based on page types.  This can be very powerful, but I don't see it adding much confusion.  

I agree that includes can get messy, however this may limit how many includes you need.  I can't tell you how many times in an include I've written <% if classname=somepagetype %>. If I ever need to write something like that it would be time to not use an include but rather create a folder, add a page.ss and a somepagetype.ss  

Anyway, I'm in favor, but also curious to hear about Hamish's work. 

[Uth]

I think the original idea of this thread is a little boxed thinking. All that I think is required is for recursive directories in the Layout and Includes folders to be applicable for template reading and including. This way any folders can be defined just like in the code folder.

Yours Sincerely,
Gary Greenberg

[Artyom]

I think there is some confusion going on. Having anything constrained
to one variable area called "Layout" at each level as you suggest is
truly a limitation. We had already mentioned above an option for
things to be infinitely definable at any level...

To be clear, the issue of having "flexiblity of folders" like you and
the other contributor above are suggesting, is a completely separate
issue and not the one that I'm suggesting we solve. I think in
practice it would very rarely be an issue.

The main issue is that there should be multiple, app defined templates
available... not just "Layout" and "Content" which is what SSViewer is
currently hard-coded to support. I'm suggesting that either

1) There is a way to specify others, like
SSViewer::AddTemplatesPlaceholders("Header", "Sidebar"

or

2) Anything that ManifestBuilder finds will automatically be
accessible in the templates under its folder name.

Sam and others have rightly pointed out that there are several ways to
go, with the issue of what to do with nested layers...

Sam's suggestion is that templates in say

/Layout/UpperArea
/Layout/LowerArea

be only visible within templates that are in /Layout. That uses the
files system to define and reflect the scope of the template, as it
currently does.

You are hilighting another issue, which is that you would like to be
free of the limitation of where templates have to live and you'd like
to organize them into subfolders as you like. This is potentially a
competing concern. If in fact there is agreement that this is an
issue, and something we should solve (which I'm a bit skeptical about,
actually), then we could perhaps have a hybrid solution:

We only have 1 level of template variables, so

/Layout
/Content
/Sidebar
/Header

could all be there at the top level, and then the the parser just
treats all the subfolders as flavors of that template, like so

/Layout/About/
/Layout/Programs/
/Layout/Media/

would all be treated as the same namespace, similar to how mysite/code works.

Personally I am with Sam, and think that having a generalized,
recursive solution is the cleanest and most useful way. Having a
hybrid system whereby new templates are only definable through the
filesystem (or config file) at the top level, and then can be
organized in subfolders has potential for confusion, and takes away
some useful flexibility, all the while solving a "problem" that very
very few sites would actually have.

I hope this clarifies the conversation a bit, because these really are
separate and somewhat competing concerns.