each panel has to have a different wicket:id and the id should not exist in component hierarchy yet. component resolvers are only used if wicket cannot match wicket id to an object in the component hierarchy.
-igor On Tue, Sep 8, 2009 at 5:51 AM, Chris Colman<chr...@stepaheadsoftware.com> wrote: >> eg you can use IComponentResolver and create a factory panel that can >> create a child based on the attributes of a tag, etc. >> >> -igor > > Well it worked well to a point. That point was when I tried to place two > panels of the same type but with different attributes on the same page. > > The second panel simply uses the first it seems, pulling it from the > cache based on it's wicket:id value. Because a separate instance of the > panel is not created the attributes set on the second panel are never > read - it is presented as a clone of the first, including the affect any > of its visual attributes had. > > > > There are only 10 types of people in the world: Those who understand > binary, and those who don't. > > >> -----Original Message----- >> >> On Mon, Sep 7, 2009 at 5:23 PM, Chris >> Colman<chr...@stepaheadsoftware.com> wrote: >> >> you say it is laughable to require knowledge of code to configure >> >> this. i agree, but i also think its laughable to require the > knowledge >> >> of markup, why shouldnt a sysadmin be able to change this? so isnt > a >> >> property file, or a jndi property, or a database table a better > place >> >> to configure this? >> >> >> >> -igor >> > >> > Property files, jndi properties and database tables are all in the >> > programmer's domain yet control over the 'size' of something, which > is >> > what this essentially is, has always and should remain, IMHO, in the >> > domain of the graphic art department - heck, we all know they are >> > experts at making the eye candy. >> > >> > The whole object oriented component architecture on which wicket is >> > built is all about building web pages from components to make it > easy to >> > create something that works but it also visually appealing. There's > a >> > lot of experimentation by graphic designers with dimensions, colors, >> > shapes, forms etc., and they're used to being able to quickly and > easily >> > try different elements and adjust their size fairly easily. >> > >> > A natural extension to this would be that panels that merely contain > a >> > variable number of items (eg., songs or news items or interesting > links) >> > should be able to be 'sized' by specifying an item count in the > markup >> > that includes them - not via 'remote control' in a configuration > file or >> > database or something else that is in the domain of the programmer. >> > >> > I don't want me or other programmers to have to recompile a Java > file or >> > set up a value in the database each time they want to change the > number >> > of items appearing in a particular panel - especially when that same >> > panel can be used differently in multiple markups. >> > >> > The decision as to how many items appear in a panel that is merely a >> > container of items is a purely visual one - nothing to do with > business >> > rules, logic or coding. It should therefore be up to a visually > oriented >> > person's point of view - not a programmer's point of view (as a >> > programmer I am therefore visually challenged ;) ). >> > >> > If anything it could be argued that the migration of the control of > such >> > a 'visual consideration' out of the model/controller (panel java > class) >> > and into the presentation layer (markup) is in fact move *towards* > MVC >> > rather than away from it. >> > >> > > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.82/2351 - Release Date: > 09/07/09 >> 18:03:00 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
