this is a matter of what is configurable externally and what is configurable internally in code. you want to reuse the markup as the external configuration medium by adding this information there, but it can just as easily live in an external property file or in a database table. the philosophy of wicket is that markup is for generation of display, not for configuring the behavior of your application. another problem is that the component hierarchy is dynamic so there is no easy way to figure out what exact tag in markup a component is bound to - this information is evaluated last and is only available during render time.
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 On Mon, Sep 7, 2009 at 4:10 PM, Chris Colman<chr...@stepaheadsoftware.com> wrote: > When my web designer guy wants control over whether he wants to place > either 10 songs or 50 songs into the 'top of the charts' panel I > consider that to be something that should definitely not be something we > have to make separate .java panel classes and markup to achieve. > > To have to get a programmer to adjust code to change the number of items > displayed in a list would be the subject of thunderous laughter in any > desktop app development environment - but yet I see that web app > development changes all the rules about what's funny and what's not =) > > In every other aspect of OO coding since 1990 a scenario like this would > cause a big light bulb in my head to go off and the word > 'parameterization' would start blinking at me incessantly. > > We programmer propeller heads can do all the smarts on the Java side to > use a single 'SongChartPanel' to display any number of songs from a list > based on a single parameter - so long as we can get that parameter > somehow. It's still MVC because NO code exists in the presentation layer > - only a parameter is now able to be passed in. > > The value of that parameter is not considered code. Setting up a > parameter is something a web design guy can 'understand' (they set > parameter/attribute values on HTML tags all day long) and it's something > that directly affects the presentation side that he would want control > over. That gives him power. > > Without this power I have to get the programmers to create a different > panel and markup for each different song chart panel even though the > code will be exactly the same except for the terminating condition of a > for loop. That's not OO and it's not reusability. It would be funny if > it wasn't true! > > Let's say we make > > SongChartTop10Panel and SongChartTop50Panel > > (with .java and .html markup for each) > > Now he says he wants to make a top 20 list for one page and a top 40 > list for another page... the inefficiency and non OO nature of this > approach becomes apparent. > > If a simple parameter were able to be passed to the panel we could reuse > that panel code to show anywhere from 1 to n songs. > > Please don't confuse a parameter (numbers, identifiers etc.,) with logic > (algorithms, conditional statements etc.,). No one is suggesting we put > logic into the presentation layer - the pain of JSP is much too firmly > burnt into my brain to ever step away from MVC again ;) > > >> -----Original Message----- >> From: Jeremy Thomerson [mailto:jer...@wickettraining.com] >> Sent: Tuesday, 8 September 2009 8:19 AM >> To: users@wicket.apache.org >> Subject: Re: Passing parameters from markup to panels >> >> Put simply, no. In Wicket, this is considered code. And code goes in >> Java >> files. Configure it in the YourPage.java file - where you have access > to >> data sources, session attributes, the user, etc.... >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> >> >> On Mon, Sep 7, 2009 at 5:09 PM, Chris Colman >> <chr...@stepaheadsoftware.com>wrote: >> >> > I apologize in advance if there is a completely obvious solution to > this >> > that I have missed... >> > >> > Is it possible to "pass in" parameters to a panel via the markup? >> > >> > Eg., Let's say that there are number of different ways that a > particular >> > panel could be rendered and that these ways are largely determined > by >> > the choice of data source or perhaps even the amount of data to > display >> > (from a collection for example). >> > >> > Now let's say that I wanted to provide some level of control over > which >> > data source is chosen by allowing the user to pass in an extra >> > 'parameter' in the markup when declaring the panel in the source > markup >> > like: >> > >> > <span wicket:id="myPanel" wicket:attribute="value" /span> >> > >> > So for example we might have a panel that displays the 'top 10 > songs' or >> > the 'top 50 songs' on a music site. The panel is exactly the same in >> > each instance but the markup container that uses that panel can > control >> > how many songs are displayed via specification of an extra parameter >> > ('count' in the following example). >> > >> > Eg., >> > >> > One page could have a lot of space and so decide to show the top 50: >> > >> > <span wicket:id="songChart" wicket:count="50" /span> >> > >> > However another page that is more dense might only have room to > display >> > the top 10 songs >> > >> > <span wicket:id="songChart" wicket:count="10" /span> >> > >> > But in each case the markup and code for the panel itself does not > need >> > to change. >> > >> > > --------------------------------------------------------------------- >> > 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 >> 06:40: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
