Hi,

next ot question how the menu is being implemented I would recommend
to have a POC that has the same amount of pages as the live project.
The reason for this proof of concept project is to check two things:
a) How is the performance in SmartEdit?
b) How long does a publication take?

Especially b is very important. From what I've seen on the screenshots
under the url http://designm.ag/inspiration/mega-menus I'd say, that
the size (height & width) is big, but the number of items shouldn't be
a problem. But -and that's the point- I've seen at least one project
that had a really big menu (5 levels, hundreds of pages within the
navigation) and everything worked fine during the first phase of the
project. But as the project grew and grew, the performance wasn't too
impressive and the publication took very long time. So depending on
the implementation this isn't necessarily an issue, but better test it
before you decide to use this or that kind of solution.

Maybe on SolutionExchange there is someone who already has a plugin,
that can create pages automatically.

Best regards,
Manuel

On 6 Dez., 21:42, Jian Huang <[email protected]> wrote:
> Hi,
>
> First, thank you for been descriptive, the existing experimental
> results are most refreshing and welcoming.
>
> So.
>
> It depends how frequent the mega menu changes, if not so often, #1
> might not be a bad idea.
>
> With the periodic publication schedule in mind, I would recommend
> using #2 over #3 because
>
> a) "Insert placeholder for page in container" option is broken in 10.
> Only fixed in 10.1 SP2 Hotfix 4.
>
> b) "Insert placeholder for page in container" option seems to work
> better over the anchor option because each time a page is published,
> page in the special container is always published.  If one publishes N
> pages, the page referenced or connected to the special container get
> published N times.  If one has different publication packages
> connected to that special container at different pages, then the page
> referenced or connected to the special container get published to many
> different places.  One will start to noticed same page being in many
> different directories.  Then one will start to noticed pages
> disappearing for no reason on full site or sectional publishing.
>
> Please note that #2 and #3 comes with another con, performance of CMS:
>
> Each time a user views a page in SmartEdit, Page preview or publish a
> page, CMS has to not only generate that page, it has to generate the
> XML/HTML file for mega menu generation.  This scalability issue is
> often overlooked because it only happens post project implementation
> when there are more users and content within the system.
>
> Best of luck and please post should you have questions.  If you have
> another product related idea, please post them 
> tohttp://www.solutionexchange.info/
>
> -Jian
>
> On Dec 6, 2:23 pm, Jian Huang <[email protected]> wrote:
>
>
>
>
>
>
>
> > Yes yes and yes!  I did 3-4 projects using them.  I have rendertag,
> > RQL, preexecution, JavaScript.  There are pros and cons to each.  Will
> > answer in detail in next post.
>
> > -Jian
>
> > On Dec 6, 12:28 pm, another developer <[email protected]>
> > wrote:
>
> > > Has anyone implemented a Mega Menu 
> > > (e.g.http://designm.ag/inspiration/mega-menus/)
> > > using RedDot/Open Text WCM.
>
> > > I have a few ideas but am not sure about the best approach.
> > > Here is what I have though of, Option 3 appears to be the most viable
>
> > > 1. Have a container in every Foundation Template that references a
> > > page with all the Mega Menu items.
>
> > >    Cons,
> > >    The Mega Menu will be present on every page in the site which will
> > > be ~3000 pages
> > >    The Mega Menu will contain links to all the 2nd and 3rd level pages
> > > (~150 pages)
> > >    If any of the Mega Menu items change (e.g. page title, filename,
> > > add/remove item, reordering) it will trigger a full site publish
> > >    A full site publish currently takes ~ 1-2hrs therefore any slight
> > > change in the Mega Menu could have a massive impact on the CMS
>
> > > 2. Put the Mega menu in a page that sits outside the navigation and
> > > publish as a separate XML/HTML file.
> > >    The XML/HTML file can be included/rendered in the page on the fly
> > > using .NET/Javascript
>
> > >    Pros
> > >    Changes to the Navigation will not kick off a full site publication
> > > like in option 1
>
> > >    Cons
> > >    I did a small proof of concept using workflow and related pages
> > >    Changes to the Navigation didn't kick off a publication of the
> > > separate Mega Menu XML/HTML file.
>
> > > 3. Have a container in every Foundation Template that references a
> > > page with all the Mega Menu items.
> > >    Similar to option 1 but the template that contains the MegaMenu
> > > will be configured to "Insert placeholder for page in container" in
> > > the template variant properties.
> > >    This setting will publish the MegaMenu page as a separate file.
>
> > >    Pros,
> > >    Changes to the Navigation will not kick off a full site publication
> > > like in option 1
>
> > >    Cons,
> > >    Initial testing showed that the Mega Menu page published correctly
> > > if any changes are made to the navigation.
> > >    However if the page does not, i.e. RedDot thinks the page has not
> > > changed then the Mega Menu could become out of date.
> > >    If the Mega Menu becomes out of date, then menu item links could
> > > become broken.
>
> > > Additional Considerations
>
> > > The implementation could be made more robust by the following:
>
> > >    a) Publish the Mega Menu file on a schedule every 20 minutes to
> > > ensure that the Menu is up to date
> > >    b) build some logic into the MegaMenu to remove any menu items
> > > which link to a page that doesn't exist.
>
> > > Additional Info
>
> > > The CMS sits behind a corporate firewall so I would not be able to use
> > > RQL on the fly.

-- 
You received this message because you are subscribed to the Google Groups 
"RedDot CMS Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/reddot-cms-users?hl=en.

Reply via email to