> I seemed to remember writing a post about something similar to this.... > here > it is: > > http://www.nabble.com/Wicket-and-CoC-tt20706881.html#a20715349
Good post. The IComponentResolver is already used heavily in our app to convert wicket:id values into panel class names but I was seeking a way to pull in other attributes contained in the tag to affect 'visual only' aspects of panel - I'm doing some experimenting with ComponentTag.getAttributes() - it looks like the one!! > It's pretty old, but probably still works. I was impressed at the time > with how easy it was. > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > On Mon, Sep 7, 2009 at 9:47 PM, Chris Colman > <chr...@stepaheadsoftware.com>wrote: > > > > officially we will not support this type of control because there are > > > plenty of other alternatives which we find more appealing. that said, > > > there are plenty of ways for you to accomplish what you want, we do > > > not slam doors on ideas just because we dont agree with them. > > > > > > eg you can use IComponentResolver and create a factory panel that can > > > create a child based on the attributes of a tag, etc. > > > > Arh, that's good to hear =) - the IComponentResolver direction was where > > my 'smoke and mirrors' approach was heading. > > > > So is it possible for the IComponentResolver to pick up other attributes > > within the tag in the container markup that instantiated a panel? > > > > Any pointers to examples of this or where I'd find the right calls in > > the API to pull in these attributes? > > > > Regards, > > Chris > > > > > > > > -igor > > > > > > 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 > > > > > > 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
