Do we want to move in a direction where every base application has
dynamic links like these? IMO the answer is no.
In the MyPortal application it would make sense to do this, but in the
Example app because of what it is meant for we should just use a
static menu widget and not have a dynamic portal-style menu.
In other words, my vote is for reverting this and going back to the
plain/normal menu widget. This dynamic app bar would be great for the
MyPortal application (which I can't wait to see in the framework with
a few role-specific default portal setups loaded in application and
specialpurpose components or whatever).
-David
On Feb 4, 2009, at 6:12 AM, Bruno Busco wrote:
Hi Jacopo,
I agree with you, the Example (and all application) should follow
the common
pattern to implement the AppBarMenu (with menu widget).
The reason the example component has been reverted to use a .ftl
AppBar was
to have a dynamic AppBar.
Actually the menu-items that are displayed in the Example AppBar are
retrieved from a dynamic list (read from the DB) so that all available
portal pages are displayed in the bar.
I think that this could be solved if we improve the Menu widget so
that it
could accept a map containing the menu-items to display.
I have proposed this on the ML but no comments yet. May be this time
I will
get better luck! ;-)
-Bruno
2009/2/4 Jacopo Cappellato <[email protected]>
Hi all,
due to recent work on the Portal now the Example application is
rendering
the top menu using an ftl template and not as a Menu widget
definition (as
it was previously, if I am not wrong).
Is there a reason for the switch (sorry but I still don't know much
about
the Portal framework)?
I think the Example application should demonstrate all our best
practices,
and using menu widget is one of them.
Jacopo
