thats pretty strange, create a unit test and we will fix it. -igor
On Mon, Sep 7, 2009 at 9:00 PM, Chris Colman<chr...@stepaheadsoftware.com> wrote: >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
