Re: [Wicket-develop] handleUnknownComponents

Eelco Hillenius Tue, 07 Dec 2004 10:47:03 -0800

Yep. Those IModels can be really powerfull. That coupled to custom components (maybe even custom rendering) might do the trick?

 Eelco

Christopher Turner wrote:

> 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.

I think this is where the confusion is occurring that makes everything more difficult. Wicket should never determine anything based on a business rule. This it the responsibility of your component and model implementation. All that Wicket should know is that you have instantiated a component of type Menu called, say, "menu" and that this has been referenced on your HTML page.

The way that I would suggest you do this is to define your own Imodel implementation called MenuModel something like:

public class MenuModel implements IModel {

// Methods for iterating over the menu items (and their children). // These methods should also be aware of security related considerations // so that they only return the menu items that can be seen }


Then define a menu component that uses this model as its base:

public class Menu extends HtmlComponent {

        public Menu(String name, MenuModel model) {
        }

        // Override the render methods to use the menu item
        // iteration methods in the model as opposed to the
        // getObject() method of the ordinary model
}

I think the key point here is that we should not always be forced to work only with the generic IModel interface. Where components have a more complex model that encapsulates many business rules then there in absolutely nothing wrong with defining a more complex model interface and having components depend on this. Sometimes trying to do everything in a totally generic way is actually counter productive and leads to increased complexity and poor design.

Regards,
Chris

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: 07 December 2004 10:23
> To: [EMAIL PROTECTED]
> Subject: Re: [Wicket-develop] handleUnknownComponents
>
>
> 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
>
>

------------------------------------------------------- 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

Re: [Wicket-develop] handleUnknownComponents

Reply via email to