> 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
