Skip navigation
Currently Being Moderated

Some bad patterns in CQ?

Mar 9, 2012 2:39 PM

Tags: #cq5 #domain #page #jsp #jstl #pagecontent #jcr:content

A good technology often makes it easy to do the "right thing"

 

While the "right thing" is a highly controversial subject and conventional wisdom can often turn out wrong, and it can be unclear what "conventional wisdom" is on any given point...

 

I still wonder if Adobe has any responses to these specific issues:

 

1. plain old JSP has long been discouraged in favor of JSTL, yet all the examples in the documentation always show JSP. While it's not hard to use JSTL in CQ, the examples and geometrix all show jsp only. Does Adobe plan to convert these at any point? or does it espouse the view "plain JSP is not so bad"?

 

2. out-of-the box use of components stores all data in cq:Pages containing jcr:content as cq:PageContent. Except for DAM assets, this means most content naturally gets stored in property and subnodes of jcr:content. As non-trivial implementations of CQ might show... you end up needing to store data you want to reuse in those nodes. In which case, you really want your data, perhaps even most of your data in a less obfuscated location. That is, you want to be able to have nice sling-able access to your data, say /content/non-dam-reusable-data/my-domain-data, instead of /content/some-site-or-synthetic-structure/some-website-category-that- isnt-my-domain-heirarchy-but-just-view/.../jcr:content/some-containing -structure/...  ; this seems to encourage poor/oddly-accessible/highly-view-and-data-coupled heirarchies from the get-go.  I realize this would be challenging, but is there any chance Adobe will update this strategy to one supporting more user-defined domain-friendly heirarchies?

 

The underlying technologies CQ uses are quite elegant, and i'm guessing some of the implementation of CQ is too (if i could only see the source ). Don't get me wrong. I like the product.

 

But, I wonder, do others feel these interface points are valid criticisms? Does Adobe have any comment on these points?

 

Thanks for your consideration of this,

Ken

 
Replies
  • Currently Being Moderated
    Mar 9, 2012 3:10 PM   in reply to kshih@scripps

    I guess also there is not enough documentation.

     

    Most of it are tutorials oriented towards the geometrix website but if i want to do something different i am on my own.

     

    API is just a list of properties and desc sometimes do not make sense.

     

    There is a lot of trial and error that hinder your productivity.

     

    Some hands-on examples in the APIs wouldn't hurt!

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2012 8:06 AM   in reply to kshih@scripps

    Hi!

    kshih@scripps wrote:

     

    1. plain old JSP has long been discouraged in favor of JSTL, yet all the examples in the documentation always show JSP. While it's not hard to use JSTL in CQ, the examples and geometrix all show jsp only. Does Adobe plan to convert these at any point? or does it espouse the view "plain JSP is not so bad"?

     

    JSTL is supported with CQ, and you can hook in custom taglibs (in an osgi bundle, the tld file needs to be at META-INF/taglib.tld to be picked up). There are several useful tags in cq (cq:include, cq:defineObjects, cq:text), documented here.

     

    It's true that most of the JSPs in CQ use java snippets instead of being JSTL only - but I don't agree to the "plain old JSPs have been discouraged in favor of JSTL" mantra. It depends. Generally forbidding java snippets in JSPs cuts of flexibility a lot. I agree that more generic logic should be outsourced to OSGi services or Java helpers in bundles, where you can test it better. And this can be made simpler by providing tags for using them. But there is a thin line between flexibility and maintainability here - if you need to write a JSTL library for everything, you introduce a new layer to maintain and with additional complexity. Some of the CQ jsps ootb might not be optimal. But don't forget that CQ is a framework and you can build the components the way you want (even choose whether they should use java servlets, JSPs or whatever scripting language runs on the JVM).

     

    2. out-of-the box use of components stores all data in cq:Pages containing jcr:content as cq:PageContent. Except for DAM assets, this means most content naturally gets stored in property and subnodes of jcr:content. As non-trivial implementations of CQ might show... you end up needing to store data you want to reuse in those nodes. In which case, you really want your data, perhaps even most of your data in a less obfuscated location. That is, you want to be able to have nice sling-able access to your data, say /content/non-dam-reusable-data/my-domain-data, instead of /content/some-site-or-synthetic-structure/some-website-category-that- isnt-my-domain-heirarchy-but-just-view/.../jcr:content/some-containin g -structure/...  ; this seems to encourage poor/oddly-accessible/highly-view-and-data-coupled heirarchies from the get-go.  I realize this would be challenging, but is there any chance Adobe will update this strategy to one supporting more user-defined domain-friendly heirarchies?

     

    I don't fully understand the question. Is it about the difficulty to model an (unstructured) content hierarchy when coming from relational database models?

     

    You are right that the content structure is usually view-oriented. I would call this resource-oriented, which is the whole point of a web server: processing requests (via HTTP), providing resources for consumption by clients. cq:Page as a node type itself can be seen as a very generic type. The term "page" might not even be generic enough; it could also be a document, article, etc. Anything that can have a hierarchy (child pages) but also contains fine-granular content (document content beneath jcr:content). The benefit is that it gives you the authoring interface for free, site management, replication etc.

     

    Cheers,

    Alex

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 26, 2012 12:23 PM   in reply to aklimets

    I'm new to CQ, and I'm also struggling with issues number 2 above (The storage of data against nodes of type cq:Page/jcr:content).

     

    It seems to cut out a lot of the functionality of a JCR. You essentially end up storing and retrieving content in what feels like a quite tenuous manner (by the existence of a specific property, or the data's existence relative to another node). For a loose bit of page content on a single site, I don't mind that so much. For anything more substantial my instincts tell me to set up a new node type, or some form of centralized store (say for instance if storing news articles that are to be used across a number of sites in the same CQ instance). My instinct tell me to configure the data in a way that is disconnect from it's circumstances, so that it can be reliably reused in different ways (not just in a specific configuration of nodes), so maybe as nt:unstructured nodes under a specific path that is away from /content, or as a new node type that can be searched from installation wide. JCR examples outside of CQ seem to back up that direction.

     

    But because CQ doesn't have any kind of interface for creating data away from the cq:page type, I'm at a loss on how to implement this. Data pulled in from external SQL sources comes in this way - but I want to store my data in CQ not outside.

     

    aklimets wrote:

     

    The benefit is that it gives you the authoring interface for free, site management, replication etc.

     

    I get what you mean by authoring interface, but I'm not sure what is gained in terms of site management? Data Management side I might be forced to duplicate data for reuse, which increases the management involved, and I don't look forward to future redesigns where my ability to identify the composition of a site can only be done by insider knowledge of tenuous properties.

    In terms of replication, it seems to be the opposite. Surely I have to physically copy data nodes to reuse content? Whilst at the same time adding multiple checks and balence's to make sure that duplicated data doesn't start to show up in what should be distinct listings.

     

    Maybe I'm missing something very fundamental? I am new to all of this. Like the original poster I generally have positive feelings towards the product, I'm just struggling to connect the dots with only limited examples available.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 26, 2012 3:39 PM   in reply to John Mawer esq

    For starters, I highly recommend to read http://wiki.apache.org/jackrabbit/DavidsModel (also part of the official documentation: http://dev.day.com/docs/en/cq/current/howto/model_data.html ).

    John Mawer esq wrote:

     

    I'm new to CQ, and I'm also struggling with issues number 2 above (The storage of data against nodes of type cq:Page/jcr:content).

     

    It seems to cut out a lot of the functionality of a JCR. You essentially end up storing and retrieving content in what feels like a quite tenuous manner (by the existence of a specific property, or the data's existence relative to another node). For a loose bit of page content on a single site, I don't mind that so much. For anything more substantial my instincts tell me to set up a new node type, or some form of centralized store (say for instance if storing news articles that are to be used across a number of sites in the same CQ instance).

    Avoid custom node types (rule #1 of Davids model). Mark the type through a property, which is much more flexible, in Sling/CQ that is the sling:resourceType, on which all the rendering is based.

    My instinct tell me to configure the data in a way that is disconnect from it's circumstances, so that it can be reliably reused in different ways (not just in a specific configuration of nodes), so maybe as nt:unstructured nodes under a specific path that is away from /content, or as a new node type that can be searched from installation wide. JCR examples outside of CQ seem to back up that direction.

    The decision where to put things is separate from node types etc. In CQ, /content is used for all content to be rendered, authored, modified by users. Just use the right structures below if you need to separate things. Usually the first level below content are separate (web) sites. Then drive the structure, and usually ACLs are a good indicator (rule #2).

    But because CQ doesn't have any kind of interface for creating data away from the cq:page type, I'm at a loss on how to implement this. Data pulled in from external SQL sources comes in this way - but I want to store my data in CQ not outside.

    As a developer, you have CRXDE and CRXDE lite (and the old content explorer) to manage & create any type of JCR nodes (apart from programmatically via the API). But if you want to give authors ways to create content, cq:Pages with templates is the way to go. Don't be irritated by the name "page" - see this as a generic "document" type, which could also be an article, a teaser snippet (see /content/campaigns for example), a web-based excel sheet, etc. And you have the option to break your documents down into components and get the flexibility of the drag-and-drop authoring interface (with the parsys).

     

    If you import/migrate data from an external DB, store them in your desired cq:Page structure right away.

    In terms of replication, it seems to be the opposite. Surely I have to physically copy data nodes to reuse content?

     

    There are basically two ways: reference content (using path references in a property, not the jcr reference, see rule #5), e.g. the standard reference component is a simple example. You want to do this if the content will always be the same for all cases that reference it (obviously).

     

    The physical copy is needed if the business case will require it, i.e. if it might be the same in the beginning but can evolve separately. For this use the LiveCopy/MSM functionality in CQ which will automate the copy process and is integrated into the authoring UI (again this is for cq:Pages).

     

    Cheers,

    Alex

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 27, 2012 9:06 AM   in reply to aklimets

    My instinct tell me to configure the data in a way that is disconnect from it's circumstances, so that it can be reliably reused in different ways (not just in a specific configuration of nodes), so maybe as nt:unstructured nodes under a specific path that is away from /content, or as a new node type that can be searched from installation wide. JCR examples outside of CQ seem to back up that direction.

    The decision where to put things is separate from node types etc. In CQ, /content is used for all content to be rendered, authored, modified by users. Just use the right structures below if you need to separate things. Usually the first level below content are separate (web) sites. Then drive the structure, and usually ACLs are a good indicator (rule #2).

     

    I follow rule #1 and started to create my data model using nt:unstructure regardless of node types. i created a hierarchy like this:

     

    (model 1)

     

    /content/mySite/home/

    /content/mySite/article/one/picture/

    /content/mySite/article/two/

    /content/mySite/article/three/

    /content/mySite/comments/

     

    then I ran into the same issue mentioned above CQ forces you to use a specific structure to implement the site like this:

     

    (model 2)

     

    /content/mySite/home/jcr:content/

    /content/mySite/article/jcr:content/

    /content/mySite/article/one/jcr:content/

    /content/mySite/article/one/jcr:content/picture/jcr:content/

     

    by default CQ will save the page "author content" in jcr:content. However what will happen if later on i want to change the structure of my website, say i want to have an east cost and west cost version. the articles for the east cost will stay as they are but for the west cost will be broken into sports, politics and economy?

     

    so what I did is to keep my original data model (model 1) where all my "author content" is saved in the way i want and independent of the website structure. Then I created my website using (model 2).

     

    Now i know sling will dispatch any node in (model 1) in whatever format I want for instance "json". So I used ajax and html form to load and save the "author content" in the (model 1) while keeping it separate from the website structure (model 2)

     

    This way if i want to change the website there is not impact on the "author content" and I can have as many websites as I want consuming the same information, for instance I may have an east-cost, west-cost and mobile website reading and writing to it. Additionally I can further organize my information i.e.  jcr:content only has "website related information": author, creation time, resourcetype, css information while the (model 1) nodes only have "author content" related information i.e. title, publication date, category, description, status. which should make it easier to sort and search.

     

    You can also used the properties of the CQ dialog widget to have your CQ system to save it's data in a different place other than jcr:content. However I think this is not working smoothly since it does additional ajax calls that may impact performance. CQ should make it easier to let you choose where will be the default node to save "author content" other than "jcr:content" and have more fine-grained events in the widget API when data is loaded or saved from a place different than "jcr:content".

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 27, 2012 1:18 PM   in reply to aklimets

    Thanks for the advice. I'd considered including the 7 rules in my original post because of it's use of the nt:unstructured, as opposed to cqPage/jcr:content. I see what you're getting at by using resourceType (I coincidentally came across resource.isResourceType() yesterday).

     

    Is there much of an over head in the search to looking up nodes based on property, as opposed to looking up nodes based on type?

     

    As a developer, you have CRXDE and CRXDE lite (and the old content explorer) to manage & create any type of JCR nodes (apart from programmatically via the API). But if you want to give authors ways to create content, cq:Pages with templates is the way to go. Don't be irritated by the name "page" - see this as a generic "document" type, which could also be an article, a teaser snippet (see /content/campaigns for example), a web-based excel sheet, etc. And you have the option to break your documents down into components and get the flexibility of the drag-and-drop authoring interface (with the parsys).

     

    Just to confirm your approach: If you had a product array, you would build a product page template, and get your users to navigate to a designated area and add the product by using "add page"? Would you store the properties of product as part of the page settings, or would you get them to drag a "product" component onto the page and edit its settings? I recently started to play with Scaffolding which looks to be a potential way to approach this?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 27, 2012 1:31 PM   in reply to ernestlv

    @ernestlv: Thanks for the example, that's also very helpful.

     

    Two questions:

     

    If I follow you correctly model 1 is built using nt:unstructured and feeds the page nodes. How do your authors maintain the content in nt:unstructured? Do they use CRXDE: Lite, or have you created a special admin interface?

     

    How do you keep your data store off the web(maybe you don't)?  It lives inside /content so is publically accessible. Could it live under a different base node (/etc or /lib)?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 27, 2012 3:18 PM   in reply to John Mawer esq

    @john: you can put the "author content" outside "/content" for instance using:

     

    /myContent/myWebsite/home

     

    prob that is better. not sure if CQ will put any complains when you want to export it though in any case you should be able to restrict access using the CRX ACL. My website is not in prod yet so we will start tackling security concerns in the next stage.

     

    and yes model 1 is using nt:unstructured and feeding the page nodes.

     

    I have sort of an admin interface for instance if i access the home page using this url:

     

    http://mywebsite.com/content/home.edit.html

     

    that will get the "author-data" using ajax from:

     

    "/mycontent/home.json"

     

    and then will put it in an html form that i get via the sling "edit" selector in the original url.

     

    i used the html form action like this:

     

    <form action="/mycontent/home">

     

    that will save the data in the crx node that i want, when i submit the form.

     

    please note you need the ":redirect" sling action to customize the response you get after submitting the form

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 11:17 AM   in reply to ernestlv

    ernestlv wrote:

     

    by default CQ will save the page "author content" in jcr:content. However what will happen if later on i want to change the structure of my website, say i want to have an east cost and west cost version. the articles for the east cost will stay as they are but for the west cost will be broken into sports, politics and economy?

     

    so what I did is to keep my original data model (model 1) where all my "author content" is saved in the way i want and independent of the website structure. Then I created my website using (model 2).

     

    When changing the structure of your websites, the point of using jcr:content or not should be irrelevant. Changing the structure basically means changing the "outer" hierarchy. jcr:content is only there to separate that outer hierarchy from the inner document structure (and inner hierarchy if you so will).

     

    However, in case you build "normal" websites, I strongly urge to use cq:Pages all the time. Not doing so just forces you to reimplement many features in CQ (or find workarounds).

     

    My original advise was meant for cases that are not directly "normal" websites, like e.g. configuration pages, more dynamic apps, where people usually do not think about cq:Pages first. In these cases it might be less required to use cq:Pages, but it is still a recommendation to use them as well.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 11:32 AM   in reply to John Mawer esq

    John Mawer esq wrote:

     

    Thanks for the advice. I'd considered including the 7 rules in my original post because of it's use of the nt:unstructured, as opposed to cqPage/jcr:content. I see what you're getting at by using resourceType (I coincidentally came across resource.isResourceType() yesterday).

     

    Note that the rules in David's model are generic to JCR. If you use Sling/CQ as a JCR-based application, things are more specific. Hence cq:Pages is a good advice to use in CQ. Note that the jcr:content child node is usually of type cq:PageContent and that inherits nt:unstructured. The cq:Page node type restricts the outer hierarchy structure a bit by not allowing residual (arbitrary) properties, but still it allows any kind of child nodes. In case you want to extend that in certain cases, use a mixin that might e.g. add certain properties.

     

    Is there much of an over head in the search to looking up nodes based on property, as opposed to looking up nodes based on type?

     

    No, the search index stores node types just like properties. The only point is that when you use inheritance a lot, with a JCR xpath query like //element(*, my:NodeType) you automatically retrieve all node types that inherit my:NodeType as well, whereas with the sling:resourceType and the sling resource inheritance you'd need to build your query more extensively. But that's actually a rare case.

     

    Just to confirm your approach: If you had a product array, you would build a product page template, and get your users to navigate to a designated area and add the product by using "add page"? Would you store the properties of product as part of the page settings, or would you get them to drag a "product" component onto the page and edit its settings? I recently started to play with Scaffolding which looks to be a potential way to approach this?

     

    That depends :-) But in general, building things like the "product" as its own component that can be embedded into the general page layout is highly recommended. You usually want to separate the inner content of a web page from the navigation, header, footer, etc. Then you can either have a generic page template with a parsys in the center where you drag'n'drop the component or you build a dedicated template that already has that component included (either using the parsys or a template using a page component that statically includes the product component in the center).

     

    Scaffolding is meant for providing a single & simplified config UI for all properties of all components on your page. It is an alternative UI to the normal authoring interface, reducing the freedom what authors can do by reducing it to a big form field. Usually it conflicts a bit with having a dynamic parsys on the page.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 11:36 AM   in reply to John Mawer esq

    John Mawer esq wrote:

    If I follow you correctly model 1 is built using nt:unstructured and feeds the page nodes. How do your authors maintain the content in nt:unstructured? Do they use CRXDE: Lite, or have you created a special admin interface?

     

    I would not force authors to use crxde lite, as you can't customize the UI with proper widgets. And I would not build a special admin interface, unless you like to do extra work :-)

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 11:45 AM   in reply to ernestlv

    ernestlv wrote:

     

    @john: you can put the "author content" outside "/content" for instance using:

     

    /myContent/myWebsite/home

     

    prob that is better. not sure if CQ will put any complains when you want to export it though in any case you should be able to restrict access using the CRX ACL. My website is not in prod yet so we will start tackling security concerns in the next stage.

     

    As noted before, everything that is authored and rendered to the public should reside under /content. Things outside /content are not covered by the siteadmin, so you would need to build your own UI. You need to additionally check ACLs and dispatcher rules that normally apply to /content/*, as you now have to take /myContent/* into account as well. And probably more...

     

    There is semantically no difference in putting things under e.g. /content/shared than under /myContent - it's just namespacing. You are free to use as many levels below /content as you want - there is no need that every direct child of /content is a publicly exposed website root. How you expose it to the public is part of ACLs (on publish) and dispatcher/apache rewrite rules (most websites have e.g. a rule that rewrites mycompany.com to /content/mycompany on the dispatcher).

     

    and yes model 1 is using nt:unstructured and feeding the page nodes.

     

    I have sort of an admin interface for instance if i access the home page using this url:

     

    http://mywebsite.com/content/home.edit.html

     

    that will get the "author-data" using ajax from:

     

    "/mycontent/home.json"

     

    and then will put it in an html form that i get via the sling "edit" selector in the original url.

     

    i used the html form action like this:

     

    <form action="/mycontent/home">

     

    that will save the data in the crx node that i want, when i submit the form.

     

    I guess you do this because you want to offer this interface to end users, i.e. surfers on publish instances? Because for cms authors on the author instance there is no reason not to use the standard component dialogs and authoring d&d UI (with content finder & sidekick) in my opinion. Unless you like the extra work or cannot live with the extjs dialogs at all ;-)

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 11:50 AM   in reply to aklimets

    Thanks for taking so much time to reply. This does all make sense, and is very helpful. My final question then would be this:

     

    By add the product (or other data type) as a component, the complete body of products in the site consists of the arrogate of all the product nodes attached to the pages.

     

    If I now want to create a different taxonomical path (I'm ultimately thinking about the addition of facetted navigation to the system), or a new site that uses a subset of those products (plus more of it's own), what is my method for doing this:

     

    A) Copy the pages I need and update templates in new location.

    B) Create a new component that uses a path to reference a product on the other site. (how then do I arrogate a search, and what if a third site and my user has to know where to navigate to get the original? Can I create a widget that searches the sites for all product nodes, and allows my user to select.)

    C) Move to the model where data is added using a page template, and keep all products outside of the sites in /content/myProducts.

     

     

    Thanks in advance...

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 1:55 PM   in reply to aklimets

    When changing the structure of your websites, the point of using jcr:content or not should be irrelevant. Changing the structure basically means changing the "outer" hierarchy. jcr:content is only there to separate that outer hierarchy from the inner document structure (and inner hierarchy if you so will).

     

    However, in case you build "normal" websites, I strongly urge to use cq:Pages all the time. Not doing so just forces you to reimplement many features in CQ (or find workarounds).

     

    @alex thanks for taking the time to answer my comments.

     

    i agree we should save everything under "/content" and we should enforce the "cq:page" type for all page related content and functionality.

     

    however there are pieces of reusable information where "cq:page" might deliver  a convoluted model. For instance:

     

    Suppose I create a "home" page for "mywebsite.com" and I follow the standard CQ way to handle cq:pages. I will have something like this:

     

    /content/mywebsite/home/jcr:content

    /content/mywebsite/home/jcr:content/par/navegation

    /content/mywebsite/home/jcr:content/par/content-left

    /content/mywebsite/home/jcr:content/par/content-right

     

    now suppose the information in the "navigation" & "content-right" components is going to be reused across all pages in the desktop website. how would you handle that? do we duplicate those nodes for each page? or  do we create a model like this:

     

    /content/shared/navigation

    /content/shared/content-right

     

    and have that model to feed my pages?

     

    Also would you create "/content/shared/navigation" as a "cq:page" even though it is never going to be displayed on its own but as a section of some other page?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 2:09 PM   in reply to aklimets

    I guess you do this because you want to offer this interface to end users, i.e. surfers on publish instances? Because for cms authors on the author instance there is no reason not to use the standard component dialogs and authoring d&d UI (with content finder & sidekick) in my opinion. Unless you like the extra work or cannot live with the extjs dialogs at all ;-)

     

    There is nothing wrong with the cq:dialog except possibly for the event-model i guess there are a few events missed to grant me more control over the life-cycle of the widgets.

     

    The idea behind the html-form was because some of the components they want to implement are very complex and they are made up of lot of pieces. So cramming everything in the extjs dialog space, delivered a rather unfriendly interface to the editors. so i created the html-form approch as a way to get additional real-state and flexibility on the look-and-feel over the elements, i display to the user. granted this requires extra-work.

     

    the otherway around is to streamline the components but try to sell them that too!

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 28, 2012 5:57 PM   in reply to ernestlv

    ernestlv wrote:

     

    however there are pieces of reusable information where "cq:page" might deliver  a convoluted model. For instance:

     

    Suppose I create a "home" page for "mywebsite.com" and I follow the standard CQ way to handle cq:pages. I will have something like this:

     

    /content/mywebsite/home/jcr:content

    /content/mywebsite/home/jcr:content/par/navegation

    /content/mywebsite/home/jcr:content/par/content-left

    /content/mywebsite/home/jcr:content/par/content-right

     

    now suppose the information in the "navigation" & "content-right" components is going to be reused across all pages in the desktop website. how would you handle that? do we duplicate those nodes for each page? or  do we create a model like this:

     

    /content/shared/navigation

    /content/shared/content-right

     

    and have that model to feed my pages?

     

    Also would you create "/content/shared/navigation" as a "cq:page" even though it is never going to be displayed on its own but as a section of some other page?

     

    The use case you mention sounds like a perfect fit for the iparsys (inherited parsys), which inherits the parsys components from its parent page (or further up in the hierarchy). Then authors define the content in a root page only and it gets automatically referenced/shared across the subtree. It also allows to override this (cancel the inheritance) on certain pages and include a custom set of components.

     

    Another approach would be to use the reference component to include a component (or parsys) from another page. You don't always have to have a otherwise unused shared page structure for this, maybe one tree is the source (but also rendered to the public) and used by others.

     

    Finally, the MSM/LiveCopy that I mentioned already can be a solution if you need separate global language sites etc. which need to be linked and inherit content by default.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 29, 2012 11:16 AM   in reply to aklimets

    OK

     

    We will have to look into the iparsys in that case navigation and content-right would be regular "cq:components" rather than "cq:pages" i like that because they are just fragments not pages in itself!

     

    Thanks a lot!

     
    |
    Mark as:
  • Jeff Brown
    8 posts
    Mar 23, 2012
    Currently Being Moderated
    Mar 30, 2012 10:44 AM   in reply to aklimets

    One thing to consider or be aware of in the case of importing data metioned above into CQ from another system is that cq:Page was some overhead associated with it in terms of audit and versioning if I understand correctly?  So, if the data is not going to be changed/authored by a person within CQ (truly data, not content IMO), and it is a lot of data - IE: your entire product line, then consider either importing under a central location such as /etc/products and using the unstructured node type.  Then your product page component in /content could reference the data from /etc/products and different components may then render mixed author-able content and non-authored product data in different ways. 

     

    Another option is to just have your page components pull in the product data from the PIM or other source system, for example, real-time and not duplicate that data in CQ at all.  Pros and cons to this approach for sure, but worth consideration.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)