Multiple Section Assignment

Wednesday 11 June 2003 3:05:46 pm

Is it possible to assign an article to multiple sections? something to the effect of what this page talks about:

http://ez.no/developer/ez_publish_22/forum/setup_design/how_integrates_explain_the_relation_multisite_sections_assign_folders__1

and this suggestion page addresses:

http://ez.no/developer/ez_publish_3/forum/suggestions/sections_of_pages_with_muliple_locations

I want to display identical data within two completely different page layouts (ie pagelayout_section_1.tpl and pagelayout_section_2.tpl) and that's only possible if I am able to assign the very same object to two different sections. I know you can have an object assigned to multiple places, but there is no way, that I have seen, to assign an object to multiple section_ids

I really need help on this one....
I have tried it using eZ publish 3.0, 3.1 beta 1, and beta 2. I've also tried going into the mysql tables to manually change it, but to no avail....

Thanks,
Adam

Thursday 12 June 2003 9:59:52 am

No this does not work (all versions, inlcuding 3.1beta2), and I consider this to be a serious design flaw. It does not take the parent section id for the new node, but from the original node the object was assigned to.

You can easily test this with a the demo setup. Add for example a new location to a forum message to "my site". A link shows up in my site to the message, but when you click the link, the full view mode takes the section id and hence the pagelayout from the *original* node: you are forced back to the formums page layout.

So the publish in multiple nodes currently does not offer more than a "link". It behaves as a "related object".

Also, when you add multiple locations, child nodes for these two are completely independent. This may be desirable in some situations, but for others this is counter-intuitive. Here ez publish needs to be polished. It is probably not a matter of choosing behaviour A versus behaviour B, but the possibility to choose between behaviours A and B.

What do others think? What was the original design idea for multiple locations by the ez team and the issue of section ids?

--
edit: please respond a little to this, I want to file a bug report but want to make sensible alternatives to the current behaviour.
--

Regards

Paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Thursday 12 June 2003 3:22:21 pm

Hi Adam

I've also come across this issue and it has lead me to reconsider how I use sections in a site.

The issue is that the section_id is associated with a content object and not the node. The node "tree" contains pointers to content objects, so if an content object exists in multiple locations within the tree the same section id is used (as it is associated with the content object)

I think there may be a design flaw in this, but only in so much as how sections are used. Sections can be used to control both pagelayout and permissions. I'm not sure that combining these two things is a good idea.

I was under the impression that the new override system in 3.1 would solve this problem but unfortinually I haven't spent enough time with it yet to investigate this fully. I think these is where you have to look.

Hope this helps,
Bruce
designIT

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

Friday 13 June 2003 2:17:54 am

Bruce, I haven?t looked into the technical solutions of 3.x, but if a part of an object is used for two different purposes (as you suggest) then it is clearly a design flaw.

In fact separating content from design is one of the purposes of eZ publish, and having both the security and the site design being decided by one attribute of an object is clearly mixing of design and content.

I can?t really believe it has been done, but I haven?t done much testing of 3.x, I just have to say I am surprised.

Paul

--
http://www.vogol.com/user/spdyvkng/blog/

Saturday 14 June 2003 6:00:12 pm

If you look at the database tables the section_id is clearly associated with a content object not the node. Within the current design I believe that this is correct. However it leads to the limitations described earlier in this thread.

I view this more as a design limitation than a flaw. :)

I'm interested in hearing any comments on this issue from the ez team as I believe that changing how the sections work is a major low level change.

Cheers
Bruce
designIT

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

Monday 16 June 2003 6:09:41 am

Since showing the same module outputs in different page layouts is a basic feature of version 2 I assumed the sections worked in a similar fashion in version 3.x.

What's the schedule on the subtree override? Is there any way to imitate this with the current code? Sorry to ask before investigating, but I think this is a critical point.
On the developer side, I would agree with Paul & Co. that attaching pagelayouts to objects is not the best idea. In fact, IMHO the override system should ignore the object altogether and only be controlled by nodes.

Karsten

Monday 16 June 2003 6:41:06 am

I've just commited support for subtree overrides in revision 2737 (trunk).

You can now check if the node is under the defined subtree. Example of configuration:

[searchfolder]
Source=node/view/full.tpl
MatchFile=product_under_frontpage.tpl
Subdir=templates
Match[url_alias]=frontpage

[searchfolder]
Source=node/view/full.tpl
MatchFile=product_under_frontpage_news.tpl
Subdir=templates
Match[url_alias]=frontpage/news

The system uses the url alias function of eZ publish to determine if you are under the desired subtree.

I hope this solves the problems you've experienced with sections.

--bård

Documentation: http://ez.no/doc

Monday 16 June 2003 6:12:30 pm

Let me add my thanks!

I've got the latest revision running (2738), however I'm still not sure about how to specfically apply this fix. Could someone post an example of how to apply the fix (ie a more specific example with explanations of every step)? I'm not even sure what specific file the code from above applies to.
In which file are these entries supposed to be placed?
Does the fix work through the URLTranslator and if so is there a setting that I need to be changing after the default install to get it working?

Thanks all,
Adam

Tuesday 17 June 2003 12:20:58 am

Bruce: the node and subtree permissions are very handy since the section concept can be limiting.

It's true that this can make some problems when assigning an object under different subtrees with different permissions. But it gives alot more flexibility and on some setups it would be too much overhead to create sections for a single node.

We're of course open for suggestions on how this can be solved.

--bård

Documentation: http://ez.no/doc

Tuesday 17 June 2003 9:34:13 am

Hi all,

I'm "just" reading that thread with a lot of interest. We have no need for permission and layout "realms" yet, but we will, when we migrate from 2.2.

As I see the discussion now, sections in ezP3 have the primary objective of setting permissions, not design. This is a contrary concept to sections in ezP2, which served for Design (Layout, Language, Templates).
Plus, Permissions in ezP3 are Node-specific, not object (=content)-specific. While this may be nice in most situations, it's not the concept of ezP2 (I don't say, that it is better or worse... but different!).

So, PLEASE note the changing of these concepts and terminology for users, who know ezP2 and/or want to migrate a ezP2 system to ezP3!!!
For new ezP3 users, this is not needed, they will just be confused, but it would be a good topic for a "Upgrade Guide" or "What's different in ezP3 vs. ezP2". Community contribution somewhere?
As this is a serious and far-reaching topic (concerning permissions AND design concepts), this should be written by someone, who has a full understanding of it (=not me, yet ;) ).

Marco
http://www.hyperroad-design.com