Sorry, I hope I'll learn it soon. 

The problem to solve: Create a menu which contains items which must be
disabled at runtime depending on some kind of business information.

Reqs:
1) A HTML designer creates the look & feel of the menu
2) A more advanced component draws the information about the menu
items out of some external data store and merges the information with
the html (template) created by the designer.
3) The information about the menu items (either in HTML or external
data store) must contain some kind of identifier/information which
allows Wicket to determine (based on a business rule) if that item
should be visible or not.

Ideas on how to solve it:
A) Make use of CSS and a Wicket component which write some small piece
of javascript into the html, disabling elements matching certain CSS
selectors.
Cons: Though the information are not visible, they are still
transmitted to the user, who might use it. I'd need additional logic
protecting the page (which might make sense anyway)

B) Make use of layout themes (style) and Wickets ability to load
markup based on the styles.
Cons: You kind of misuse styles for that purpose and may clash with
the original purpose of it. You have to maintain lots of markup file,
actually one for possible combination of business roles (as in my
case).

C) Provide *all* menu item with a unique identifier, which allows
Wicket based on a mapping table and business rule, to determine which
item to disable.
Cons: Assuming the identifier is id="wcn-menuItemXXX", you have to
create a component for *each* menu item. In case of modification, you
always have to change the html as well as the java sources, which is
very awkward. Based on some kind of business logic (Boolean model
object) you disable the component. *Manually* creating the Wicket
component for each menu item is kind of boring, because the components
to be created are all the same. Another disadvantage: memory footprint
for a Page (which is kept in the session object) will increase on
every page as almost all pages contain menus. How does that impact
scaleability?

D) Mark all menu items *potentially* be disabled with
id="wcn-menuItemXX" and create a Wicket Component for each. Same as B:
The model object is a Boolean, providing the information to enable or
disable the component.
Cons: Same a B, in addition you have some kind of business logic (the
items to be disabled) in html.

Because of the disadvantages of the approaches above, I started
thinking about a single Wicket component, which like a Panel or a
Border, surrounds the menu markup and applies some kind of filter
(e.g. XSLT). This approach however has major drawbacks: a) You cannot
transform it after reading from file and prior to parsing the markup,
because the markup cache would contain business logic dependent
markup. b) You can not use MarkupStream as an input for XSLT. c)
Without significant changes to security aspects, you can not create a
MarkupStream (somehow transformed or filtered) within your component.

Than I discovered how easy it was to extend Wicket to allow for my own
[autolink] like components. Instead of [autolink] I named it
[role:XXX]. Now I was able to create the required components
*automatically* including some hint (XXX) to the component. XXX must
not necessarily be the same role name I use in my business logic. It
merely provides some additional information to the business logic to
make the decision.

Summary:
I think there are (at least) two kind of menus. Full blown ones, where
the html markup merely contains the look & feel and where an external
data store contains the (at runtime configurable) menu item and
information required for the business logic to decide which one to
print.

With the more simple menus the html markup may contain the whole menu
including all items and thus must include some kind of information of
which item to disable, no matter how the Wicket component looks like
to evaluate that information and to disable the related markup.

Any other ideas on how to solve it?

Juergen


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to