How much logic/functionality should exist in the theme and how much should

[Dennis Greiffenberg, geändert vor 12 Jahren.]

Mean reason for opening this thread is a discussion that resultet from this bug in Liferay 6.1 GA.

The summary of this bug is, that due to a change in the navigation.vm of a theme portlets could no longer be applied to a page. So Nate Cavanaugh came up with the question which is now subject of this post and I'm happy to create this post and have things discussed.

Any feedback / thoughts are welcome

/Dennis

[Dennis Greiffenberg, geändert vor 12 Jahren.]

I really think the navigation should remain part of the theme as I appreciate the fact, that it does not necessarily need a developer to change things here.
The navigation has to be amended every now and then as per the projects specs, sometimes you just need the toplevel, sometimes you need two, three or more.
Liferay is flexibel enough to handle all that, but if it wasn't in the theme it would become more difficult / complex to keep dedicated navigation-styles for different sites.
So my first thoughts would be: Leave this feature as is

Best regards,
Dennis

[Nate Cavanaugh, geändert vor 12 Jahren.]

Hi Dennis,
Thanks so much for creating this thread

I don't think we have any plans on removing the navigation from the theme. I think being able to control that would be far too common of a need to have us remove it.

However, the parts where I'm curious about is with functionality that gets added to the items in the themes.
For instance, like the issue in the LPS ticket you referenced, that bug was introduced by functionality that is added in by the portal level, but depends on the navigation having a certain markup.

We have a few examples of this in the portal. For instance, the fact that the portlet titles are editable, that functionality is added by the portal, but it depends on there being a certain piece of markup in the portlet.

If we place too much of the admin interaction on the theme level, it makes the themes extremely complex and fragile (as well as harder to update and fix bugs), but by having it on the portal layer, it also makes it more difficult for theme developers to remove that functionality.
(Actually, we have different ways of disabling a lot of this stuff currently, for instance, if you place the css class of "not-editable" on the ".portlet-title-text" element, then the editable title functionality can be removed; likewise you can remove sorting or adding functionality from the navigation by removing either "sort-pages" or "modify-pages").

One idea I've been kicking around, and you tell me how you would feel about it, but I've been contemplating whether to move this functionality out into macros that generate the expected markup, and *only* using those macros in the classic theme. If someone wants to add that functionality, then they could use the macro to generate the navigation for them.

As an example, let's say we wanted to have a navigation that was editable, it could be optionally used in the navigation like so:

#editable_navigation()

And that would replace the current loop.

I've already implemented something similar in one of my github branches for an infinite level drop down menu navigation (the only reason I haven't committed it to upstream is because of issues around the editable aspect).

But, I'm curious to hear what you think about that kind of separation. It's a tradeoff (control of the markup vs. stability in the additional functionality), but I'd love to get feedback on where you think we should place that line.

Thanks again Dennis,

[Dennis Greiffenberg, geändert vor 12 Jahren.]

Nate Cavanaugh:

Hi Dennis,
Thanks so much for creating this thread

No probs. I'm very interested in this topic, so I'm more than happy to discuss these kind of things.

Nate Cavanaugh:

As an example, let's say we wanted to have a navigation that was editable, it could be optionally used in the navigation like so:

#editable_navigation()

And that would replace the current loop.

Puh, it's quite early and I didn't have a single cup of coffee, yet. So may be I should rather respond later in the day as my brain might become more flexible over the day ;-)

Not sure if I got you right, but I understand the navigation.vm would than contain a sum-up of function calls only, is that what you're saying?
And if so: We would again be somewhat "limited" to what Liferay provides, isn't it? In case we're asked to code something additional it could still "break" the navigation so I'm not sure that I'm fully seeing the advantages of your approach of changing the navigation in the described way.

I think -even though you put large effort in putting information in your last post- I didn't fully understand what you're trying to achieve so far.
May be you can run a 2nd attempt to put me on track? ;-)

Cheers,
Dennis

[Nate Cavanaugh, geändert vor 12 Jahren.]

Hi Dennis,
It wouldn't be the first time I miscommunicated my thoughts, so please forgive me

So, my thinking is this:

Currently, the way we advise people to build themes is through the SDK, and using our _diffs paradigm (meaning your theme "extends" from the _unstyled theme). The _unstyled theme would stay the same for the most part as far as the markup goes.
However, in the Classic theme we would place these helper macros that generate the navigation. This way, if you wanted to use a similar navigation, you could just copy that macro from the classic theme's example, and paste it in your navigation.vm.
Or if you need something more custom, you can ignore it, and implement the navigation the same way you are doing now.

Here's the tradeoff with this approach: if you need a custom navigation, you would lose the ability to have the advanced functionality (like drag and drop of nav items, editing page titles, adding new pages, etc).
On the other hand, if you are fine with the markup, you can style the nav to look however you like and still keep the functionality.

So, in your case, where you need extra nav items, you could probably still keep both and work around it (wrapping the macro with a div and placing your extra nav items in that div).

Hopefully that explains a bit more of what I was thinking. However, I'm totally open to alternative approaches that could work.

For instance, we could provide the JS calls to be used from the theme. There are 2 downsides to this: 1, if we change the component API, it will still break peoples themes who are using it, and 2, it requires the theme to manage the permissions for when it should be applied (which makes for a pretty hard to maintain theme).

Let me know if that all makes more sense. If not, I can probably address a specific use case or example, but hopefully that's all a bit clearer.

Looking forward to your feedback.

Thanks again Dennis!

[David H Nebinger, geändert vor 12 Jahren.]

I too recently created a custom navigation based upon using a dropdown menu and a 'go' button (requirements )

For my menu, the top page was converted to an <optgroup> if the page had child pages, would be just an <option> if it did not. Also the special top page "Hidden" would not be in the menu; it's child pages would actually appear as regular links in the banner area.

So much of the Liferay navigation stuff did not apply. Cannot do 'add page' from the dock as there's no area to type in the new page name. Cannot drag and drop the pages, cuz there's nothing to click and drag on. Cannot edit page titles because there is no label to overwrite w/ a text input field.

All of my page management must be done in the "Manage Pages" area where I can accomplish all of those editing things.

In this sort of scenario, I guess in Nate's book I wouldn't have any of the macro inclusions in my navigation.vm file. The problem, I guess, would be in Liferay's JS implementation that may expect my nav elements to be tabs instead of <optgroup>/<option> elements of a <select> tag.

This would be the crux of the problem. The expectation is that the JS expects elements, classes, ids to be in place. Whether we stick w/ the navigation.vm methodology we currently use or a new macro-based approach does not resolve those JS expectations...

[Dennis Greiffenberg, geändert vor 12 Jahren.]

Hi Nate,

so you're saying Liferay would then provide multiple options to build a custom navigation as if you were choosing from a construction kit?

If not, I can probably address a specific use case or example, but hopefully that's all a bit clearer.

In case it's a matter that can be done in a reasonable amount of time, some kind of practical exam / mockup could really be of help, just to make sure we really have a common understanding.

All the best,
Dennis

[Dave Kliczbor, geändert vor 12 Jahren.]

Hi all,

Could it be possible to strip the "Client-side Navigation API" down to a few clear conventions on CSS id's and/or classes? Ideally, these conventions should not exceed one page in tabular form...

Maybe I think in a way too idealized, but here are my thoughts:

• In the page JS, all you'd probably need would be a way to identify the nodes that make up the navigation: the nav-container(s) and the nav-items (including the nav-childs).
• You'd have to allow for nav-items to become a nav-container to (e.g. nested ul/li) or have the nav-container for a sublevel outside the nav-container of the first level.
• From there, you can infer additional information like the child level (e.g. from the nesting in the DOM), the position of nodes in the page and the order of the nav items.
• Maybe you can even introduce a "configuration part" where nav-nodes are "set" via XPath expressions.
• And the template designers would need an object structure behind _one_ "front object" that's able to tell them everything about the navigation thats possible to provide.

The conventions may then look like this:

• class="nav-container" -> This is one of multiple nav-containers. First one of these in the page structure would contain top level, then counting ... they may be nested or strewn all over the html code -- doesn't matter, an order could be determined. It also needs a class like "siteid-11123" to be able to correlate it with liferay objects in the DB.
• class="nav-container nav-level-1" -> Like above, but with explicitely mentioning the level
• class="nav-item" -> This node is a navigational item. It also needs an id/class like "pageid-10332" to be able to correlate it with liferay objects in the DB.
• class="nav-item-text" -> This node contains the text of the navigational item (if it does not exist, the deepest text node inside a nav-item that's not inside another nav-container would be deemed the nav-item-text).

Can anyone think of anything needed that cannot be derived from this data via JS?

These conventions could maybe hidden in the "front object" (or in the "navItem" objects found by the front object) by giving the designers the method getCssClassString() -- there you could also return some additional classes that the designers love (with semantics like "selected", "first item", "last item", "even item", "odd item", "non-modifiable", based on the properties of the pages and the rights management).

I think that the designers would then only really need the following methods:

• the navigational front object (a variable, lets say "nav")
• nav.getListOfNavItems()
• nav.getListOfNavItemsByLevel() (convenience method: returns the nav items on the current page tree path by level)
• item.getListOfChildNavItems()
• item.getCssClassString()
• item.getTitle()
• item.getTitle().getCssClassString()
• item.getHref()
• and maybe a some more convenience methods... But I think the above is fairly complete.

Any HTML that's generated from these methods can be looked at by a designer. He should understand CSS classes and the semantics behind the class name. From there, he would happily write CSS without even checking further documentation. Heck, even the most basic template would contain a simple example of using all these methods... and the documentation would fit in the file's comment.