1. Home
  2. Portal
  3. RE: 7.2 A1 - Display page

RE: 7.2 A1 - Display page

thumbnail
Christoph Rabel, modified 6 Years ago.
7.2 A1 - Display page
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
I am a bit confused now about display pages. I have created a structure, template and a webcontent of that structure type.

1) I have created a Widget page with an Asset Publisher + (Set as  default ...).

Basically the classic. And it works, but the page isn't displayed as a display page but in the normal tree. I am not sure, if this makes sense. I mean, with an asset publisher on it, it is a display page. Does it matter, if the page type is widget or standard?

2) I tried adding a content page and to make "sure", I added a few fragments to it.

But when I edit the webcontent, nope. No display page.
Then I edited the display page, mapped a few fields to the page. Ok, that works, but it is still no display page.

According to the documentation, there should be some kind of "Mapping section". But I can't find it.


3) Now I created a new content page and added an Asset Publisher, again set as default AP.

I would have expected, that I can set this page as a display page. Even if I would need to find it in the tree and select it there. But still, only the widget page created for "try 1" is useable as a display page.
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
Aargh.
I figured it out, there is an extra tab on the Pages area. I totally didn't see that.

This resolves 2), but why does this have to be an "extra type"?
thumbnail
Jorge Ferrer, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Hey Christoph,

I'm glad you figured it out.

Let me give you some more context of why things are the way they are.

The feature you are using (which we used to call "Content Display Pages") was our very first attempt in 6.x to solve the need of creating a way to display content without having to create an specific page for each of them. However it turned out to be very difficult to understand and use. We did some research and we could barely find a handful of customers who were using it.

As part of the Modern Site Building project we set out to rethink the problem from scratch. That's when we came up with the concept of "Display Pages" that debuted in 7.1 and has its own tab within Pages administration. One decision we made for the new display pages is to only support the new way of building pages called "Content Pages" since we believe it is a much better fit for the purpose of displaying specific pieces of content.

This new concept of "Display Pages" is meant to fully replace the original attempt from 6.x based on asset publisher. However, we want to make sure that original way is still available for those used to it until we have a clear upgrade path. However, knowing that it will be phased out, we have not invested in fully integrating it with the new approach (like showing the display pages all together) since it's requires a large effort. I hope that makes sense.

Have you tried the new display pages with the improvements for 7.2? I would like to hear your feedback about them and specifically if there is anything that you could do with the original approach but not with the new one.
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
I agree, the old way was somewhat clumsy and hard to explain. But we use it alot actually.

Mostly because we understand it and configure it for our customers. We also have a little JournalArticleWrapper that enforces that a display page for certain structures is set correctly.

I just tested it a bit.

For repeatable fields only the first entry is mapped. Interestingly, nested fields cannot be created with drag & drop anymore. (Edit: It works now. But I swear, I couldn't do it a couple of minutes ago.) But they still work when I write them into the source json. I can map the nested field, but the content isn't displayed.


I also checked a few structures/templates of our customers, where we need/use display pages. News, Events, Jobs, Menu (of the week), Recipe (for a menu). Can't do. Repeatable field, nested fields, display logic in the templates.

The main problem with a "fragments only" approach is that I need code. Just a few things:

1) If video -> video else fallback_image.
2) If field is not empty -> Render heading + field
3) If list is not empty -> Render heading + list items
4) If list is even/odd, apply different styling
5) Reorder items on list
6) Do something completely different: If user is in China, do not show youtube videos (YT is blocked in China)
7) Show contact data of the author (or the override field, if one was entered)
...

General verdict: Can't use, too many missing features.
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
I gave the matter some more thoughts. I really like the idea to have a simple display pages concept.
How about this:

On the display page, add a fragment-like drag & dropable "Content Display Area". This CDA can then be added somewhere on the page (probably in the center, but who knows ...) This area will then display the webcontent using the default template.

To add some icing to the cake:
- Single field mapping should still work
- Allow the editor to select a template per CDA
- Allow the editor to put multiple CDAs on a page

With this, I could keep my old templates and use the display pages instead of those Assetpublisher constructs. It would allow me to use more complicated structures with repeated and/or nested fields. And it would even be more powerful than before, since I could use the "single field mappings" too.

And it shouldn't be too hard to implement (at least V1, one CDA using the default template).
thumbnail
Jorge Ferrer, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Hey Christoph,

Thanks for all your feedback and analysis on the topic. It's very valuable for us to be able to hear from people with experience with real world templates and the "old" display pages.

Your suggestion makes a lot of sense. It is related to some of the ideas we are testing right now, although it might be simpler. Let me describe what we are trying out:
  1. Allow selecting web content templates as if they were fields (see LPS-79811). We are finding some technical difficulties, but in its most ambitious form it would allow a template developer to mark a given template as "mappable". This means that the template would appear along with the list of fields while doing the mapping, but instead of showing the value of a field it would show the result of rendering the template.
  2. Allow implementing "programmatic" components that can have access to the context and thus be able to take the displayed asset and display it in any way desired. These components would be deployed and be available always in all sites.
The first proposal in this list would be more finegrained that what you are proposing, since it would be possible to still use mapping for the simple fields and then create templates for the more advanced fields which require logic.
The second proposal could actually serve as the basis for implementing your suggestion. We could create a programmatic component which just displays the current content in a default way (in the case of web content it would be with its default freemarker template).

​​​​​​​What do you think of these proposals? 
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
About 1:
I thought about that too, but discarded it when I wrote my comment My main reason was:
a) Sometimes fields are related.

If you look at my video example:
-) If video -> video else fallback_image.
I would need acccess to two fields here. Also, my real world example is even mor complicated. There are three fields. Video Link China, Video Link World, Fallback image. Since YT is blocked in China, we need to use a chinese video service there. Youtube must never be linked.

So, I would need to map multiple fields to the template.
(Note: I could use a workaround here, like putting a nested field at the root of my structure and then traversing "manually" through the children, but that could become quite ugly, so it is kinda meh)

On the plus side: The ability to to select a template per field would solve alot of usecases. It would e.g. allow the rendering of lists, which is quite a big usecase. But again, it doesn't solve everything.


b) Practical consideration
I thought, that it was difficult to implement, while my solution is rather simple and could be implemented quickly., it could probably even be added to 7.2. A drag&drop "fragment" with a journalarticleDisplay.getContent() shouldn't be too difficult to add to the Mapping part of the display pages.

c) Management of templates
We currently have about 50 Templates. With the current backend it is really hard to keep track of them. With even more templates, more snipped like, you would need to totally revamp the management interface. It could use a makeover anyway, but that's another story.
In any case -> This needs time.


About 2:
 I am not sure, I understand this one. So, instead of the ability to select/use a freemarker template, I deploy a service, the editor selects it in dropdown box and that service would then render the content in whichever way it deems necessary (e.g. by calling the freemarker template)?

This indirection could be useful, we currently enable serviceLocator all the time. With that approach, I could a) prepare the data or b) inject the service from the component.

Drawback: I would need to write a service. With the simple ability to simply "display the full webcontent" I would need to do nothing (as a developer) and could just write the template. If I migrate, I probably already have a template, I just replace the old Asset publisher display page with a new display page. Design it and drag&drop a "display linked webcontent" view somewhere.
thumbnail
Jorge Ferrer, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Hey Christoph,

Thanks for your answer. I've added my comments on both of the topics below:

1. Allow selecting web content templates as if they were fields (see LPS-79811)

Thanks for the example of the video, that case would definitely be supported. In this proposal, any template can behave "as if it were" a field and then use the full power of freemarker to display or take into account as many fields as desired.

The way the templates would be provided to the user would be in the same select box where currently the user is selecting a field while mapping (either for display pages or the new way to display an specific content within any fragment)

Initially we thought of allowing the user to select any template for the structure. But it might mean that too many options are provided. An alternative would be to provide a checkbox (or similar) in the configuration (Details) of each template that needs to be selected to make the template available for mapping. What do you think is best?

2. Allow implementing "programmatic" components (see LPS-91856)

My previous explanation was not very good, so I'll try again with code. The idea here is to provide the interface below (still subject to improve). Third party developers (and ourselves) can then create implementations which will appear to users in the page editor as a component that can be added to any section column in the page.  

public interface FragmentRenderer {

    public String getCollectionKey();

    public String getLabel(Locale locale);

    public default String getType() {
        return "component";
    }

    public default boolean isAvailable(HttpServletRequest httpServletRequest) {
        return true;
    }

    public void render(
            HttpServletRequest httpServletRequest,
            HttpServletResponse httpServletResponse, String mode)
        throws IOException;
}
The key benefits of these way of implementing fragments are:
  • Since they have access to the request, they can have more complex logic, including based on context (such as obtaining the current asset in a Display Page).
  • By being implemented in Java they can have better performance and allow choosing your templating library of choice.
  • The isAvailable() method can control when the component will be applicable (for example, only for display pages)
Do you see yourself using this capability?
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
1. Allow selecting web content templates as if they were fields

Ok to a)
But I still am concerned about c)
b) is not so much of a concern since I can continue to use the old "display pages".

My main concern is the management of the templates. For our "top customer" we have 27 templates and 44 ADTs. With this, they would explode.
events_heading, events_footer, events_video_with_fallback, events_date, ...

I think, the ADT/template list has to be reworked too, for this to work.
And there has to be a way to limit the number of options for the editor. Permissions are not sufficient here. Maybe a categorization would help. I mean:
a) Ability to categorize templates (maybe structures too?)
<lfr-editable mappable_categories="video">

b) Show only templates categorized with "video" in the template selector.


2. Allow implementing "programmatic" components

Ok, I understand the idea. Such a component would be quite useful. But what it also needs a configuration. That's actually a major problem of all fragments.

Suppose, I want to show the contents of a folder in Liferay. (List of files for download). Ignoring portlets, I could create a fragment and fetch the list through rest. Or use this component to prepare the list in the backend. But in both cases, I would need a place where I can at least enter the folderId. (Note: We currently put alot of stuff in custom fields, I'd rather get rid of that)

I am quite sure that we would use that feature. We currently use serviceLocator alot. In the templates we do something alog

data = ourservice.getAndprepareData(...)
Use freemarker to just render the data, we prepare the lists, sort, filter, format fields, cache them, ... in Java and then just render them through freemarker.
thumbnail
Jorge Ferrer, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
1. Allow selecting web content templates as if they were fields

Ok to a)


Great. We actually just finished the initial implementation. I hope to have it in master in a couple of days and would love you to take a look at it. I think the interaction is really nice.


But I still am concerned about c)


Yeah, I also want to find a way to solve that. When you say that you have 50 templates, are they for different structures or all of them for the same structure?


b) is not so much of a concern since I can continue to use the old "display pages".


My goal is to make the improvements necessary so that you don't want to use the old "display pages" any more. If we achieve that I'm sure they will be more useful for many other users and use cases as well.

My idea is to still implement a fragment that can render a single web content with its default template. Probably it would only be available within Display pages, to avoid confusion if used outside.


My main concern is the management of the templates. For our "top customer" we have 27 templates and 44 ADTs. With this, they would explode.
events_heading, events_footer, events_video_with_fallback, events_date, ...

I think, the ADT/template list has to be reworked too, for this to work.
And there has to be a way to limit the number of options for the editor. Permissions are not sufficient here. Maybe a categorization would help. I mean:
a) Ability to categorize templates (maybe structures too?)
<lfr-editable mappable_categories="video">
b) Show only templates categorized with "video" in the template selector.


I agree that we need to find a way to limit the options. For 7.3 I would like to do a deeper analysis and consider more complex options, including categorization as you suggest. Although we are just a few days away from feature freeze for 7.2, so it's not feasible at this point.

Because of that, I would like to find a simple way to filter that we can still implement. Do you think that offering the checkbox when editing the template that I described above would be a step in the right direction?
Otherwise, what other "simple" solution do you think would work better?


2. Allow implementing "programmatic" components

Ok, I understand the idea. Such a component would be quite useful. But what it also needs a configuration. That's actually a major problem of all fragments.

Suppose, I want to show the contents of a folder in Liferay. (List of files for download). Ignoring portlets, I could create a fragment and fetch the list through rest. Or use this component to prepare the list in the backend. But in both cases, I would need a place where I can at least enter the folderId. (Note: We currently put alot of stuff in custom fields, I'd rather get rid of that)


Yeah, having configuration is part of the plan. Our idea so far is to leverage the Configuration framework introduced in 7.0, where the developer can just create an interface and the configuration UI will be created programmatically. In a first version we would support the simple fields that are already supported, but we can easily support more advanced fields that leverage the different selectors of the product.


I am quite sure that we would use that feature.


Awesome. I'll continue looking forward for your feedback on the topic. Feel free to add them to the JIRA ticket as well as we make progress.
thumbnail
Andrew Jardine, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 2416 Join Date: 12/22/10 Recent Posts
Hey Guys.

I haven't chimed in on this but it's great thread -- and I'm looking forward to this for sure. I owuld like to add though that, like Chris, I also carry around with
me a wrapper that auto-sets display pages (when configured to do so). It was developed in part to solve the problem of trying to explain it as well, but also because people complained about the extra clicks, or sometimes forgot to assign a page.

I think if it were possible to also include something like this as part of this feature improvement, it would be useful for many clients. 

​​​​​​​Just my two cents.
thumbnail
Jorge Ferrer, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Hey Andrew,

Thanks for participating in the conversation.

With the new Display Pages introduced in 7.1, it's possible to set a Display Page as the default for an specific web content structure. That way there is no need to set it content by content (which is only needed when a different display page is desired).

Would that solve the need you have found?
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
Jorge Ferrer
Yeah, I also want to find a way to solve that. When you say that you have 50 templates, are they for different structures or all of them for the same structure?
Well, this was just one customer, but in general:
For webcontent it is usually one template per structure. We have a few cases, where we have a "preview template" and a "full content template", but these are usually just one or two (news, events).

For ADTs, it's complicated. Several of our ADTs are actually little applications. They call services and we use freemarker to display the data. The simple ones just show asset lists in one form or the other (banner carousel, news, events, jobs, ...). I always wanted to replace the Asset publisher with a "template viewer", but I never found the time to do it.

Jorge Ferrer

My goal is to make the improvements necessary so that you don't want to use the old "display pages" any more. If we achieve that I'm sure they will be more useful for many other users and use cases as well.
Oh, I don't want to use the old pages, I can clearly see the advantage of the new ones. But I expected these feature with the template mapping to arrive only 2020 or so.


My idea is to still implement a fragment that can render a single web content with its default template. Probably it would only be available within Display pages, to avoid confusion if used outside.
Yes, I agree here.


Because of that, I would like to find a simple way to filter that we can still implement. Do you think that offering the checkbox when editing the template that I described above would be a step in the right direction?
Otherwise, what other "simple" solution do you think would work better?
Hard to say. We are talking about ADTs here, right? (I mean, they are added to the ADT area and not to the Webcontent Template area)

How about a "structure selector"? The creator of the "fragment template mapper" chooses either "All" or selects the structure to which the template applies.
That way, when an event structure is mapped to a page, only mappers that are applicable to events and "All" are shown. I believe, the number of generic mappings should be rather small.

This shouldn't be hard to implement and is vastly more flexible than a checkbox.


Yeah, having configuration is part of the plan. Our idea so far is to leverage the Configuration framework introduced in 7.0, where the developer can just create an interface and the configuration UI will be created programmatically. In a first version we would support the simple fields that are already supported, but we can easily support more advanced fields that leverage the different selectors of the product.
In my opinion: Simple fields already solve 95% of the problems. When we implement configuration pages, most of the time it's just text fields. Sure, customers would like to have more comfortable options, but in the end, the wallet decides that they can live with "Enter the id of a user or webcontent article" instead of a "webcontent/article selector".
thumbnail
Jorge Ferrer, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Christoph Rabel
Jorge Ferrer
Yeah, I also want to find a way to solve that. When you say that you have 50 templates, are they for different structures or all of them for the same structure?
Well, this was just one customer, but in general:
For webcontent it is usually one template per structure. We have a few cases, where we have a "preview template" and a "full content template", but these are usually just one or two (news, events).
Ok, great. That makes things much simpler.

Based on my research it seems that the number of templates per structure is usually small so it's safe to list all templates as if they were fields for mapping. See the screenshot attached to check the current implementation (the last entry in the "Field" selector is a template)


Jorge Ferrer
My goal is to make the improvements necessary so that you don't want to use the old "display pages" any more. If we achieve that I'm sure they will be more useful for many other users and use cases as well.
Oh, I don't want to use the old pages, I can clearly see the advantage of the new ones. But I expected these feature with the template mapping to arrive only 2020 or so.
Glad to hear that you see the advantages. And even more glad to hear that we are overdelivering emoticon



My idea is to still implement a fragment that can render a single web content with its default template. Probably it would only be available within Display pages, to avoid confusion if used outside.
Yes, I agree here.

Awesome



Because of that, I would like to find a simple way to filter that we can still implement. Do you think that offering the checkbox when editing the template that I described above would be a step in the right direction?
Otherwise, what other "simple" solution do you think would work better?
Hard to say. We are talking about ADTs here, right?
I was actually talking about web content templates. Which makes things much simpler since we are already filtering by structure.

The use case for which you are using ADTs is a bit more complicated, but one that I would definitely like to dig deeper on after the 7.2 release.



Yeah, having configuration is part of the plan. Our idea so far is to leverage the Configuration framework introduced in 7.0, where the developer can just create an interface and the configuration UI will be created programmatically. In a first version we would support the simple fields that are already supported, but we can easily support more advanced fields that leverage the different selectors of the product.
In my opinion: Simple fields already solve 95% of the problems. When we implement configuration pages, most of the time it's just text fields. Sure, customers would like to have more comfortable options, but in the end, the wallet decides that they can live with "Enter the id of a user or webcontent article" instead of a "webcontent/article selector".
Awesome. Keep an eye on the JIRA ticket to see progress in this area. Will look forward for your feedback.

Attachments:

thumbnail
Christoph Rabel, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
Ah. I made a mistake here by assuming we were talking about ADT templates. Webcontent templates not only make things easier, but also make much more sense for the usecase display page + mapping of templates to fields.

Note:
I still think that the overview pages for templates (especially ADT) should be reworked. But that's a different, actually unrelated story (and maybe will even become obsolete due to the other changes)
Lee Jordan, modified 6 Years ago.
RE: 7.2 A1 - Display page
Expert Posts: 449 Join Date: 5/26/15 Recent Posts
Again this is a great discussion. One issue I see with display pages is that users (site admins) won't "get it" ... because it looks far too abstract. So as a portal admin I could set up display pages for a user to show events, but the amount of time I would need to take to train those users is immense (or more accuratly I would have to train my support team to train my site admins).

As an example I set up an asset publisher to show documents from a certain category like "Patient Informaton Disclosure" but that was tagged "Retired" so it shows on the "Retired Policy Page" and not the "Active Policy Page". This has caused immense confusion because even though you can do this ... training users in management of content via Vocabluary is ridculously strenous. Even something as simple as is in this category with this tag.

Now if you say "Hashtag" rather than "Tag" it does spark a get it moment.

That user would then still go back to Basic Web Content and struggle with Alloy Editor because that was easier to comprenend (and honestly a lot faster for the user struggling with abstracted features like this) in order to add or remove a link to a document. Users want speed and even if you try to automate something for them users will do what's fastest and easy for them to "get". That may involve avoiding the cognitive load that we as designers are capable of.
thumbnail
Christoph Rabel, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
Lee JordanAgain this is a great discussion. One issue I see with display pages is that users (site admins) won't "get it" ... because it looks far too abstract. So as a portal admin I could set up display pages for a user to show events, but the amount of time I would need to take to train those users is immense (or more accuratly I would have to train my support team to train my site admins).
There's a difference here. The old way was really, really complicated. I mean, to explain what that checkbox does and that they need to set a display page and ... Urks.

With the new page it is a lot simpler.

But I agree in one thing: That discussion about template mappings is all nice and fine and will allow the admins and some clever people to do a lot of things. But for most people it is probably better to have less options.

-) Create page
-) Add some fragments and enter text there
-) Select a content type (aka structure)
-) Drag and drop that content are on the screen


As an example I set up an asset publisher to show documents from a certain category like "Patient Informaton Disclosure" but that was tagged "Retired" so it shows on the "Retired Policy Page" and not the "Active Policy Page".
I totally get what you mean. Some editors drive me nuts. emoticon
thumbnail
Jorge Ferrer, modified 6 Years ago.
RE: 7.2 A1 - Display page
Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Thanks for the feedback Lee and Christoph!

This is aligned with our vision since it is our goal to empower non-technical/business people to be able to do more and more on their own. And we believe one key to achieving this is empowering developers/IT to prepare things to what their specific users will need and understand.

With Display Pages in particular, we have lowered the bar versus what the product had before. We definitely don't want to stop here though. We have a series of ideas from more specialized page types (with a structure), explicit listing of the display page (instances), etc. This will be one of the areas of focus for 7.3.

Will keep you guys updated.
Lee Jordan, modified 6 Years ago.
RE: 7.2 A1 - Display page
Expert Posts: 449 Join Date: 5/26/15 Recent Posts
Absolutley and simplifying things for users is awesome.

For display pages to succeed I think portal and site admins should have an in depth "Cookbook" type blog from liferay explaining display pages. Not just "this is display pages" in documentation but an actual pathway to success by example.

Or leverage youTube in laying down a path to sucess for us by way of walkthrough videos ... that would be awesome and I'm minded to drop that in on slack to documentation. I look at the Raspberry Pi Community and not only is documentation in the community via blogs and boards (Liferay do this too) but the community contribute a tonne of look what I did type videos that are 21 minutes of nerds typing in commands. I can't see why that wouldn't work for DXP. In depth with display pages.