Modules in component layout

[Babs Gösgens]

Hi,

I have a couple of question regarding templating:

1) Is it possible to render a module inside a component template or inside another module? I want to render the breadcrumbs in different positions, depending on the view, so I would prefer to load them from within a view layout rather than from within the page layout.

2) Looking at application/page/templates, it appears that it is possible to assign different page layouts. How would I apply that to a specific page? For instance, I would like to render the login page in a different layout void from any modules.

Thanks, Babs 

ᐧ

[Babs]

Quick answer to question 1: it is possible to load a module on other layouts than templates. I had tried before but I had mistyped the module position and so it didnt work :P

[Johan Janssens]

Hi Babs,

1. Yes this is possible.You can render modules for a specific module position using <ktml:modules position="[position]"> tag where [position] is the name of your module position. This works everywhere.

For more advanced use you can also do 

<ktml:modules position="[position]">

   <ktml:modules:content>

</html:modules>

Here the contents of the module position will be injected into <ktml:modules:content> this allows to do additional wrapping for example see : default.html.php#L27

You can specifiy an additional "chrome" parameter when rendering a module. The chrome will contain the name of a chrome wrapper for your modules.

This works both in the framework and the platform, in the framework modules can be managed through Joomla, while the platform comes with a pages component that handles module management.

2. Application layouts are loaded using the 'tmpl' query paramereter. For example to use the login layout you would either through the url or through the API set the 'tmpl' to 'login'. 

In case of the login layout this is done using the unauthorized event handler and the layout is forced in the request through code. See : unauthorized.php#L43 You could also pass the layout to your URL ?tmpl=mylayout. 

It's however recommend not to add to many additional layouts. We believe we have covered most use cases for layouts already, right now the platform has following layouts :

- default : to render a normal page

- dialog : to render a dialog box

- error : to render an error

- overlay : to render an overlay, used by the overlay helper

- login : to render the login page

If you wish to change how the login page works it would be best to override the template, or in case you are creating your own application you do have to create it of course and have full control over it.

Additional note : the login template doesn't control if it loads modules or not though. Modules position tags can be included anywhere in the rendering pipeline. If you look at both login layouts in the platform you will see that both don't define any module positions. They just define where the content of the component is injected through using <ktml:content> 

Does that help ?

Johan

[Babs Gösgens]

Hi Johan,

Thanks. I found the block implementation of the module (<ktml:modules></html:modules>) which I find very cool btw.

Regarding question two, I wanted to assign a different page layout for only the landingpage and the login and signup view. Now, the login and signup I control by (un)assigning modules, but in the case of the landingpage I have a little more changes from the 'regular' layout that apply. I somehow expected that to be configurable from the pages component by assigned page-wide layouts on that level.

I suppose I could get around this keeping the default page layout really bare and check for the existence of modules, however I would also need some method to identify the current view so that I could - for instance - apply a specific body class to control which styling applies. I suppose I could check which view is being rendered, or map page ID's or something, but adding it to the page configuration as a class or something seems appropriate. I guess we override the some of the configuration files to add such behavior.

I'll figure this out, am trying to stick to Nooku best practices where possible.

In the meantime, what is the way to check for modules (in a specific position) in a template? 

ᐧ

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

--

---
You received this message because you are subscribed to the Google Groups "Nooku Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framewo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Johan Janssens]

Hi Babs,

Great to hear you like modules implementation. About your layout issue. We simply never had a use case to be able to configure layouts per page. 

The best solution for your use case would be to add this feature instead of trying to hack around it. This could be a nice contribution for you to make ?

Cheers,

Johan

To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framework+unsubscribe@googlegroups.com.

[Johan Janssens]

About your question. We have a helper to count the modules in a certain position. See : https://github.com/nooku/nooku-platform/blob/develop/component/pages/template/helper/module.php#L87

Call it as helper('module.count', [condition]); Example helper('module.count', 'user1 + user2');

Does that help ?

Johan

On Monday, November 10, 2014 6:16:32 PM UTC+8, Babs wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framework+unsubscribe@googlegroups.com.

[Babs Gösgens]

It does, thanks :)

I'll keep you posted on the page configuration solution that we ultimately end up with.

ᐧ

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framewo...@googlegroups.com.

[Johan Janssens]

Great, if you need more help let me know.

Johan

[Babs Gösgens]

Hi Johan,

I found a bug in the way module blocks are parsed. In a nutshell, the closing tags are never removed, thus invalidating the markup (and breaking the layout). I have issued a PR with a proposed patch: https://github.com/nooku/nooku-platform/pull/16

ᐧ

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framewo...@googlegroups.com.

[Babs Gösgens]

Actually - strike that (i haven't fixed it). There's something else going on. This only happens on certain views in our site, will investigate a little further to find what's causing the tags to be rendered correctly sometimes and not other times.

to be continued...

ᐧ

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

[Babs Gösgens]

ᐧ

The issue does not reproduce itself consistently, but the problem seems to be in parsing the nested <ktml:modules:content> tag.

This works ok:

<ktml:modules position="navbar">

    <ktml:modules position="navbar__menu">

    <ktml:modules position="navbar__user">

</ktml:modules>

But this does not (some of the times):

<ktml:modules position="navbar">

    <ktml:modules:">

</ktml:modules>

In the last instance, the nested modules do not get rendered, and the last two <ktml:modules:"></ktml:modules> tags are not removed.

My first hunch was that there had to be a problem with markup elsewhere on the page, maybe a mismatched tag or something. However, I have inspected all output and wasn't able to find anything.

No action is required as I can solve this by nesting the actual module tags, but the behavior is strange and should probably be investigated further.

Thanks!

On 13 November 2014 09:49, Babs Gösgens <ba...@crossinghippos.nl> wrote:

Actually - strike that (i haven't fixed it). There's something else going on. This only happens on certain views in our site, will investigate a little further to find what's causing the tags to be rendered correctly sometimes and not other times.

to be continued...

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

On 13 November 2014 09:42, Babs Gösgens <ba...@crossinghippos.nl> wrote:

Hi Johan,

I found a bug in the way module blocks are parsed. In a nutshell, the closing tags are never removed, thus invalidating the markup (and breaking the layout). I have issued a PR with a proposed patch: https://github.com/nooku/nooku-platform/pull/16

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

On 12 November 2014 07:01, Johan Janssens <jjan...@gmail.com> wrote:

Great, if you need more help let me know.

Johan

On Tuesday, November 11, 2014 4:22:32 PM UTC+8, Babs wrote:

It does, thanks :)

I'll keep you posted on the page configuration solution that we ultimately end up with.

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

On 11 November 2014 06:26, Johan Janssens <jjan...@gmail.com> wrote:

About your question. We have a helper to count the modules in a certain position. See : https://github.com/nooku/nooku-platform/blob/develop/component/pages/template/helper/module.php#L87

Call it as helper('module.count', [condition]); Example helper('module.count', 'user1 + user2');

Does that help ?

Johan

On Monday, November 10, 2014 6:16:32 PM UTC+8, Babs wrote:

Hi Johan,

Thanks. I found the block implementation of the module (<ktml:modules></html:modules>) which I find very cool btw.

Regarding question two, I wanted to assign a different page layout for only the landingpage and the login and signup view. Now, the login and signup I control by (un)assigning modules, but in the case of the landingpage I have a little more changes from the 'regular' layout that apply. I somehow expected that to be configurable from the pages component by assigned page-wide layouts on that level.

I suppose I could get around this keeping the default page layout really bare and check for the existence of modules, however I would also need some method to identify the current view so that I could - for instance - apply a specific body class to control which styling applies. I suppose I could check which view is being rendered, or map page ID's or something, but adding it to the page configuration as a class or something seems appropriate. I guess we override the some of the configuration files to add such behavior.

I'll figure this out, am trying to stick to Nooku best practices where possible.

In the meantime, what is the way to check for modules (in a specific position) in a template? 

[Johan Janssens]

Hi Babs,

You have a typo here : <ktml:modules:"> should be <ktml:modules:content>  The tag is parsed literally, if you have typo it will not work.

Could this be the issue ?

Johan

[Babs Gösgens]

improper copy/paste only in this e-mail, I'm afraid :) 

ᐧ

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framewo...@googlegroups.com.

[Johan Janssens]

Thanks Babs, you say : does not work some of the times, have you consistently been able to replicate the issue  ? What is the exact code you are using that doesn't work ?

Johan

[Babs Gösgens]

Yes, the issue manifested itself only on one view in our app. It replicated consistently - whenever I ecapsulated the modules:content inside a module block, parts of the lower html would be 'sucked up' by the regex (as Oli confirmed) and the component tags would not be replaced/removed. I have also tried nesting the individual module calls but when I nested more than two the same behavior started to occur.

I have now resorted to placing only single-level modules so I can't show you any example of it at this point. I can assure you however that I have examined all output for markup errors but coulndt find anything that could have caused this.

ᐧ

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framewo...@googlegroups.com.

[Captain Oli]

For context, this started happening when the module tag format was changed to HTML5 and the trailing slash removed. It then becomes much more difficult to tell the difference between a single module tag <ktml:module> that is never intended to have a body, and <ktml:module></ktml:module> tag, for example:

<ktml:module position="top">

<ktml:module position="bottom">

</ktml:module>

the regex can't tell which opening module tag the closing tag corresponds to, this is why regex is not great at html, especially HTML5 that lost the closing slash on single closed tags.

The only way I solved this in the mean time was to always use open tags and not the closed style.

[Johan Janssens]

Hi Babs,

Would it be possible to provide me with the exact html code you used that generates the issue ? Without the code I'm running a bit blind. Happy to see if the regex can be improved to resolve this issue.

Thanks,

Johan

[Babs Gösgens]

Hi Johan,

Unfortunately I reverted our code to just use single modules, so I removed the nesting. At this moment, I don't have time to reproduce the former situation as it involves creating a couple new modules etc.

However, just add this to any existing theme and check the rendered output (use self-closing and not self-closing tags for different results):

<ktml:modules position="[position]">

   <ktml:modules:content>

</html:modules>

You'll see lot's of stray module tags left in the markup:

ᐧ

Met vriendelijke groet,

Babs Gösgens

Crossing Hippos

http://www.crossinghippos.com

To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framewo...@googlegroups.com.

[Captain Oli]

Bumping this.

So, here's the code that causes a problem

<nav>
    <ktml:modules position="menu">
</nav>
<ktml:modules position="left" chrome="wrapped">
    <aside class="sidebar col-md-3">
        <ktml:modules:content>
    </aside>
</ktml:modules>

This results in a capture of:

<ktml:modules position="menu">

</nav>

<ktml:modules position="left" chrome="wrapped">

    <aside class="sidebar col-md-3">

        <ktml:modules:content>

    </aside>

</ktml:modules>

Because the first regex is:

#<ktml:modules\s+position="([^"]+)"(.*)>(.*)</ktml:modules>#siU

which is matching from the menu module position, through to the closing of the left module position. The (.*) is what's capturing from menu to the closing tag.

Previously, the syntax was 

<ktml:modules position="menu"/>

Thus allowing the regex to differentiate between the two types.

[Johan Janssens]

Hi Oli, 

Bump received. Doing a regex for this is hard, we would need to write a forward looking regex. That leaves us with two options :

1. We parse the template markup using an xml parser, to get the various elements out.

2. We go back to self closing tags.

Thoughts ?

Johan

[Oli Griffiths]

Xml parsing is probably adding unnecessary overhead, if a forward slash can do it. 

Given that <ktml:modules> isn't valid html5 without a namespace anyway, I don't see the need for using the open tag version. 

Thoughts?

--

[Johan Janssens]

True, for the sake of simplicity using a self closing tag here makes most sense. I'll change this in develop ?

Johan

To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framework+unsubscribe@googlegroups.com.

[Oli Griffiths]

Great

To unsubscribe from this group and stop receiving emails from it, send an email to nooku-framewo...@googlegroups.com.

[John Bell]

I would agree with self closing tags too, probably solve some issues I had as well.

John

[Johan Janssens]

Hello all,

A little update on this. As part of my recent Template refactor I have moved to using self-closing start tags for the modules tag. Related ticket: https://github.com/timble/kodekit/issues/64 

Please note that these tags are now called <ktml:block> and the implementation of them has been generalised. The change is triggered by the html spec itself which states that when elements which can have content are used empty they need to have a self-closing start tag. 

More info: 

- http://www.456bereastreet.com/archive/201005/void_empty_elements_and_self-closing_start_tags_in_html/

- http://w3c.github.io/html/syntax.html#elements-0

Happy coding,

Johan

[Oli Griffiths]

Excellent!

Great work.