Re: [Wicket-user] Wicket customizability

[Wander Grevink <w....@hippo.nl>]

Gentlemen,

Thank you very much for these insightful answers.

Igors' IComponentFactory was just the push in the right direction that I needed. I now have a 'GenericComponentFactory' 
with a constructor that accepts a class name as parameter. This works and now I can inject any (jarred) component/panel 
into my app, great!

As next step I'm going to have a look at the wicket.properties/IInitializer mechanism. Sounds like the perfect mechanism 
for managing these plugin Components.

The system Eelco mentioned sounds very similar to the system we are intending to develop here (at hippocms.org): 
business objects that come with their own gui components. It's a good thing to hear that it's all perfectly doable :-)
Can your business objects/gui components also be created by 'others' (users)? Or do you 'own' them all yourself?

Wander

> sounds to me like what you need is indirection
> 
> something like
> 
> IComponentFactory { Component newComponent(String id, IModel model); }
> 
> then you can configure these in whatever context (in your case spring) and inject those into pages/panels/etc and 
> let them create children.
> 
> this is essentially the same as osgi or anything else would work. a "named" component factory is an osgi 
> service/spring bean/plugin/whatever
> 
> -igor

> i don't really understand what you're talking about because i don't know your requirements.  but don't forget two 
> things: 1) the primary unit of reuse in wicket is the panel and 2) you can put any component (such as a panel) in a
>  completely self-contained jar because of packaged resources.  if you just want users to be able to add panels that
>  work on entities exposed through an API maybe all you need is jarred panels.

> Also, take a look at wicket.properties and IInitializer. Basically, this is Wicket's mechanism for auto-discovery. 
> When starting up, it loads all instances of wicket.properties it can find it the (root of the) classpath, and 
> instantiates the IInitializer class that is configured in it. That initializer can then for instance register the 
> components it has in case you would work with a central component registry (sounds like this is something you might 
> want to have). OSGi can do even more for you, including automatic discovery at runtime (so you drop in a jar and it 
> should connect without even having to restart... actually now that I think of it, we could poll for new additions as 
> well if we wanted) and it provides a much broader module mechanism. Not an expert on this field though. Maybe on of 
> the OSGi experts on this list can throw in their opinion?
> 
> Btw, the system that I'm working on (and others on this list, including Igor) works like a component system where 
> business components (can't think of a better name) provide their own panels for end-users and tasks like 
> administration/ configuration of the components etc. It's all perfectly doable, but you gotta do some upfront 
> thinking :)
> 
> Eelco
> 

Wander Grevink wrote:
>> 
>> Hi all,
>> 
>> I have just created my first wicket app: a simple JCR (jsr-170) browser/editor with a tree showing nodes on the
>> left, a form for editing node properties on the right, and a menu with some actions (add, delete, save etc.) on
>> top. All 100% Ajax, it just works!
>> 
>> As a side note: I started from scratch (completely new to wicket), and it took me two weeks to learn wicket and
>> build the application. Needless to say that I'm a definite a convert, thank you guys for creating this wonderful
>> thing called wicket!
>> 
>> Now for my question(s):
>> 
>> What my shop actually needs is a customizable gui. We develop a core module and users can write plugins for it,
>> think eclipse, firefox etc.
>> 
>> I know of Pax Wicket which is an "An OSGification of the Wicket web framework". It sounds very interesting and
>> reading the documentation it looks like exactly the thing we need. However creating a 'Pax Wicket' application is
>> something very different from an ordinary Wicket app. I have the impression that 'going OSGi' is a decision
>> comparable to 'going J2EE' and should not be made overnight, but I might be wrong there.
>> 
>> I would prefer a simpler way of going this. Therefore I did some experimenting and tried to inject a wicket
>> Component (a Label) with wicket-spring, but found that injecting Wicket Components doesn't work. The proxy will try
>> to access a protected method on Component and fail. My guess is that that is a Good Thing because you're not
>> supposed to inject wicket Components this way, but I may be wrong there, am I? Is there another way?
>> 
>> What I did manage with just base Wicket was a custom ModalWindow.PageCreator that dynamically loads a Page (using 
>> Class.forName) in it's createPage() method. That works, and because the class name is stored in the Model (it's a 
>> property of the selected node in the tree) I now have a 'dynamic' modal window whose implementation (java + markup)
>>  depends on the selected treenode and can be plugged in by adding a jar file to the project.
>> 
>> However, extensibility 'just' through popup dialogs is not enough, and as far as I understand it is not possible to
>> do the same trick for 'inline' (on the main Page) Components. Or is it?
>> 
>> I guess that my question boils down to this: Am I on the right track or should I stop doing this and go to my boss
>> and tell him that we should go OSGi (and Java 5 btw. currently we are strictly bound to jdk1.4)
>> 
>> Regards Wander

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: [Wicket-user] Wicket customizability

[Eelco Hillenius <ee...@gmail.com>]

> Can your business objects/gui components also be created by 'others' (users)? Or do you 'own' them all yourself?

Sure, they could, as long as they satisfy the business component
interface. It's not something we need right now, but we could create a
separate jar with that interface, maybe supply some kind of test suite
and use a programatic registry (that e.g. could be added to using
iinitializers) instead of the spring configuration we use now if we
wanted to enable third pary development.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org