right, and the next logical extension is controlling visibility, or maybe which panel variant to display. why should the developer be involved if the designer wants panel A vs panel B, thats silly. so next step is wicket:if and wicket:else based on some condition expressed through some type of EL. once you go down this path you will end up with the mess that is jsps.
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. -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
