Home → Velocity Formats →

Page association in Velocity format

• Edit

Bryce Roberts

Aug 26, 2015 @ 01:00 PM

Hello,

I am trying to establish a method for two way association between pages. Currently I have a set of pages that use a data definition page picker to create the association. In order to process through this information at render time, it seems I need an index. Due to the size of the data structure, this becomes a significant issue for scaling to 10000+ assets to search for 10s of associations.

Two different solutions have been tried:

Cascade API:
com.hannonhill.cascade.api.operation.Read +
com.hannonhill.cascade.api.operation.Edit
However, there appears to be a private var set for 'presisted' in the read object, which prevents normal operations.
Model for this is:
Assets (Create or Edit) --> Look up relationships --> Edit relationship (inserting ID) --> on Relationship renders look up pickers through IDs

Webservice Classes com.hannonhill.cascade.webservice.handler.AssetOperationHandler:
1) Create require objects for listSubscribers method
2) Can create everything
3) Returns without error non successful and no message.
As a pure guess: it appears that structuring of the class instance is dependent on other services (Spring autowire magic), and I do not know the underlaying structures well enough to guess at how to create this. Is there a way to access the application context to get the appropriate service bean?

Thanks,
Bryce

1. 1 Posted by Ryan Griffith on Aug 26, 2015 @ 03:22 PM

   

   Hi Bryce,

   I think Cascade API via the Locator Tool in conjunction with a calling page index block so you can look up the chosen page would be the best solution here, but I'm a little unclear as to what you are trying to accomplish with the relationship.

   When you have a moment, would you be able to describe in more detail what your use case is so I can hopefully provide some more accurate information or ideas?

   Thanks!

   • Edit

2. 2 Posted by Roberts, Bryce ... on Aug 26, 2015 @ 03:53 PM

   

   Hello,

   We have a two way relationship we want to represent without have to use a page picker on both sides.

   Set of pages 1,2,3 are of type A
   Set of pages x,y,z are of type B

   New pages of both A and B are being created.

   Pages of type B pick type A pages.

   When type A page is rendered it need the full data of the the type B pages that have picked it.

   Does that help?

   Sincerely,
   Bryce

   • Edit

3. 3 Posted by Ryan Griffith on Aug 26, 2015 @ 04:10 PM

   

   Thank you for the additional information, Bryce.

   Just to clarify, when you say:

   When type A page is rendered it need the full data of the the type B pages that have picked it.

   Are you saying that you would like to list pages of type B somewhere on type A pages, and vice versa? Like some kind of "related content" listing?

   If so, there are a couple of options I can think of:

   Using a Content Type Index Block

   • Add a block chooser to the data definition for both page types
   • Create Content Type Index Blocks for both types. Optionally, limit and sort the chooser to help reduce the size of the Index Block
   • Choose the appropriate Index Block within the block chooser
   • Your Format works with the assets rendered by the Index Block
   • To handle new pages, use a base asset for each page type that has the appropriate Index Block pre-selected

   Use the Locator Tool's Query API (http://www.hannonhill.com/kb/Script-Formats/#locator-tool)

   • Use the Query API to obtain pages belonging to the desired Content Type; and optionally filter, sort, limit the results
   • Add a means of defining what Content Type the page should be associated with
     • data definition text field that has a static reference to the desired Content Type (could be hidden/restricted to normal users)'
     • put the desired Content Type within individual Formats for the page types. Optionally, move common logic into an a macro within an imported Format to maximize code re-use

   Please let me know if I am way off in left field, or you have any questions.

   Thanks!

   • Edit

4. 4 Posted by Roberts, Bryce ... on Aug 26, 2015 @ 05:39 PM

   

   Hello,

   The issue has to do with establishing the relationship on the picked asset side.

   Pages of type A need to pull information from all type B pages that it pick. On the flip side, type B pages need to know all the type A page that have picked it, and there full data structure.

   Yes, this can be done and is currently done with indexes, but this has problems with performance when scaling to 10000s of assets.

   The locator tool only is useful on the one side, but it does not expose a by to get the relationship. It would for type A page but not on type B.

   Sincerely,
   Bryce

   • Edit

5. 5 Posted by Ryan Griffith on Aug 26, 2015 @ 05:42 PM

   

   Ah, I think I'm following now. So when you say need information for the pages picked, what are you doing with said information?

   For instance, you can use $currentPage to loop over each chosen page, which will give you access to the Page objects via the Cascade API. From there, you would have access to all of that page's information.

   Please let me know if you have any questions.

   Thanks!

   • Edit

6. 6 Posted by Roberts, Bryce ... on Aug 26, 2015 @ 05:48 PM

   

   Hello Ryan,

   Yes, this work fine on the page that is doing the picking, but the $currentPage object does not include information of the relationships of that asset. This only work on the one side of this relationship.

   Model:

   Asset 1 picks Asset 2 in Asset 1's data definition.

   On render Asset 2, I need to know that Asset 1 picked Asset 2.

   The locator tool works well at render time of Asset 1 to get Asset 2. It does not provide in the Asset 2 ($currentPage is just the PageAPI object) the relationship to Asset 1.

   Sincerely,
   Bryce

   • Edit

7. 7 Posted by Ryan Griffith on Aug 26, 2015 @ 06:01 PM

   

   Ah, OK, now I got it. You are correct, this will only get you half of the equation. May I ask what your plans are there so I can get a better picture of things?

   Off-hand, I do recall a client who went with the Web Services approach you mentioned. That is, they basically had an automated job that would check relationships and update assets accordingly. You could do something similar here, where you check the relationships and update some choosers accordingly.

   If you did go this route, I'd recommend implementing some kind of local cache layer on top of this to help reduce the overall number of operations performed on Cascade. Hope that makes sense.

   Please let me know if you have any questions.

   Thanks!

   • Edit

8. 8 Posted by Roberts, Bryce ... on Aug 26, 2015 @ 06:22 PM

   

   Hello Ryan,

   I would be happy to provide a bit more detail. Yes, we have an extendable set of content 'tags' that are pages within Cascade. These are picked by a variety of other assets types (blocks and pages) that represent our content. From this, we build dynamic association that populate parts of our sites. We have implemented a WS approach to this in the past but iterating over 1000s to 10000s of assets that then update 10s to 100s of assets per call was error prone and had significant impact on performance. Resolution was to create a set of aggregator blocks of index blocks, but this also has performance issues. As we are looking at a need for more of this type of dynamic bi-directional content association, we foresee these issues growing. It would be good to find a solution that allowed for this type of association at render/publish time.

   Sincerely,
   Bryce

   • Edit

9. 9 Posted by Wing Ming Chan on Aug 26, 2015 @ 07:14 PM

   

   Ryan,

   Would you please verify that, with the possibility of direct database access using a format, one can retrieve ID's of pages being picked in a page from the cxml_entityrelation table? If this is possible, then at least we can have a set of ID's to work with. From here, we can use com.hannonhill.cascade.api.operation.Read to read the pages and try to retrieve the contents in each individual page. This approach should work for blocks as well.

   Wing

   • Edit

10. 10 Posted by Ryan Griffith on Aug 26, 2015 @ 07:26 PM

    

    Thank you for providing more detail, Bryce.

    It definitely sounds as though adding the ability to get an asset's subscribers using the Locator Tool (ie Cascade API) would be the most ideal. So in theory, you would use $currentPage to obtain the chosen assets and then loop over the subscribers of each of those assets. There's nothing being cached like with Index Blocks, but you would already have things narrowed down to that small subset of assets so it shouldn't be too bad.

    If you would like for this type of functionality to be considered for a future release, I highly recommend posting this as a suggestion to our Idea Exchange for others to vote up and/or comment on.

    In the meantime, I'm thinking the Web Services route would probably be the best workaround. Or, perhaps you could go with some kind of setup where:

    • you publish out the structured data of each of these pages as XML or JSON
    • have a web services script create additional XML/JSON files of subscriber information
    • place a script on each of these pages that does the relationship logic based on those published files
    • you could maybe name/structure these files in such a way that looking up the information is a matter of using the asset's ID or something

    Wing, I definitely had your Velocity+database stuff in mind. Although this is possible, it is definitely not something we would officially support. Adding this functionality to the Locator Tool and Cascade API would be the best solution.

    Please let me know if you have any questions.

    Thanks!

    • Edit

11. 11 Posted by Roberts, Bryce ... on Aug 27, 2015 @ 02:23 AM

    

    Hello Ryan,

    The load/performance is worse with the web service bulk work when compared to index blocks. We have some working prototypes with direct database access, but we are looking for a supportable solution. Plus since there is no locking or know control mechanism, we see issues with direct database access in a highly concurrent editing environment. Any further advice would be helpful. Are there any context aware accessor classes, which could be used to access or set the webservices bean through reflection? Is there some documentation about the implementation of the listSubscriber that could be useful? Are there other element of the Cascade API class that I am overlooking? Do you know if there is any solution to the persisted state issue on read objects? Are there any issue with dynamically changing the field state in the read object?

    Sincerely,
    Bryce

    • Edit

12. 12 Posted by Ryan Griffith on Aug 27, 2015 @ 06:21 PM

    

    Hi Bryce,

    Let me check with the developers, but off-hand I would assume that if there is something you could do programmatically as a workaround it would not be officially supported. Instead, we would look to add this functionality to the Cascade API so one can access this information natively within Velocity when working with $currentPage and the Locator Tool.

    I do see that someone from your organization submitted a suggestion for this functionality on our Idea Exchange, so that is definitely a good start.

    Curious, but is there anything you can do using the Query API and Content Types? Thinking maybe you match up the chosen assets from the query results with the current page.

    Thanks!

    • Edit

13. 13 Posted by Wing Ming Chan on Aug 28, 2015 @ 02:06 PM

    

    I agree that in most cases workarounds should be avoided, provided that there are other alternatives. But when there are no alternatives, then workarounds are inevitable. A case in mind: $currentPage is not available in XSLT. If my only choice is XSLT, then I need a workaround to recreate this variable in XSLT if I need it badly enough. This is exactly what I did with direct database access.

    Wing

    • Edit

14. 14 Posted by Roberts, Bryce ... on Aug 28, 2015 @ 02:23 PM

    

    Hello Wing,

    If you need current page in XSLT, I have a solution that does not require direct database access. It does require the calling page or other identifier, but this is true when using direct access as well.

    Sincerely,
    Bryce

    • Edit

15. 15 Posted by Wing Ming Chan on Aug 28, 2015 @ 02:37 PM

    

    Bryce,

    I would love to see your work. If you don't mind, would you please post your solution here?

    Wing

    • Edit

16. 16 Posted by Roberts, Bryce ... on Aug 28, 2015 @ 02:51 PM

    

    Hello Ryan,

    Content type indexes are not useful in this case, because we need to have the association be independent of the page type / block type. Additionally blocks are not available in in content types. Query API does not provide a method for many to many type relationship models that is extensible. It require brittle metadata based association (string matching).

    Sincerely,
    Bryce

    • Edit

17. 17 Posted by Ryan Griffith on Aug 28, 2015 @ 05:30 PM

    

    Agreed, Bryce, just trying to think of some possible native options.

    I sent a question to our developers so I'll keep you all posted if I do have any updates on whether there's another option that would be supported.

    • Edit

18. 18 Posted by thugsb on Sep 10, 2015 @ 07:07 PM

    

    This would be very helpful to have this true two-way relationship. I'd love for it to be prioritized by the developers. I've added my vote. Tx!

    • Edit

19. 19 Posted by Ryan Griffith on Sep 10, 2015 @ 08:28 PM

    

    All,

    Speaking with one of the developers, he had an interesting idea that involves Web Services and updating the assets during render inside of Cascade:

    Basically, you would host a script under some URL that would read a page with given id or path and then populate a hidden multiple page chooser on all the pages that are chosen by the current page. For example, if current page A has page choosers that choose page B and page C, then the script would populate a hidden page chooser on page B and page C with page A selected. This would create a two way relationships - one way would be the visible to the end user and the other way would be hidden.

    This script could be invoked during the page's rendering through [system-view:internal] hidden ajax request (or perhaps even a hidden <img> or <iframe> tag where the source is the script. This way basically anytime a page is edited, on first render in Cascade (so after edit submission), the script would get invoked to update all the other pages that this page selected. To help meek things efficient, you could perhaps have some logic within the script that determines if updates need to be made or not, perhaps some kind of lookup table within a local cache that gets compared to the current page's last modified time.

    • Edit

20. Ryan Griffith closed this discussion on Sep 24, 2015 @ 12:35 PM.

21. Ryan Griffith re-opened this discussion on Sep 24, 2015 @ 12:39 PM

22. 20 Posted by Ryan Griffith on Sep 24, 2015 @ 12:39 PM

    

    All,

    Not sure if you had a chance to see Bradley's roadmap presentation during the User's Conference, but he made mention to some Cascade API improvements coming down the pipeline.

    As far as I known, one such improvement would be the ability to list an asset's relationships from within a Velocity Format, basically what you would see when clicking on the Relationships tab.

    Although I do not have a timeline for the API improvements, I hope you will find them to be useful when they are released.

    Please let me know if you have any questions.

    Thanks!

    • Edit

23. Ryan Griffith closed this discussion on Sep 24, 2015 @ 12:39 PM.