RE: Passing parameters from markup to panels
Am Donnerstag, den 10.09.2009, 14:03 +1000 schrieb Chris Colman:
why? what is different between a 10 or a 50 item song panel? the
number
of items? you should anyhow use a ListView which repeats the her is
the
song-block as many times as you want to..
It is using a ListView - the desire was to provide an easy way for the
UI guy to specify a row count in the markup.
ok.. i got this.. i would put it into an property file of the component
where the SongPanel is used and put a ResourceModel as parameter to
SongPanel
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.
why do you make this?
They each derive from SongChartTopPanel and invoke the constructor with
a different row count - but without parameterization and using standard
simple wicket devices (i.e. not component resolvers) then we need a
separate markup and separate .java class for each panel that has a
different number of songs displayed.
you can override getVariation to switch between markup.. so if you use
the ResourceModel for this, this should be easy..
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.
Yes but you'd still require a separate markup for each one I would think
- without going the with component resolver approach.
i am not sure, that i understand this problem as it is.. so excuse, if
my solutions does not fit..
The web designer will have a nice 'Top 10' image above the panel so I
didn't want to put it in the hands of the user who might change the
rowcount to 13 or something. 'Top 13 songs around the country this week'
doesn't sound right - especially if the image above it says 'Top 10'.
ok..
some code to show you my view of this problem and the solution (may not
fit)..
class SongPanel ..
{
SongPanel(String id,ResourceModel topCountAsStringModel)
{
final int count=getCountAsInt(topCountAsStringModel,10);
IModelSong model=new LoadabledDetachModel()
{
load() { ... getSongs(count) }
}
add(new ListView(songs,model) {..}
add(new Image(topImg,new ResourceReference(getClass(), topImage,
getLocale(), top+count)))
}
getVariation()
{
return top+count;
}
}
SongPanel.html
wicket:panel
Top 10 (default)
img wicket:id=topImg
tabletr wicket:id=list.../table
/wicket:panel
SongPanel_top50.html
wicket:panel
Top 50
img wicket:id=topImg
tabletr wicket:id=list.../table
/wicket:panel
ComponentA(String id)
{
add(new SongPanel(songs,new ResourceModel(songsInList,));
}
ComponentA.properties:
songsInList=10;
ComponentB(String id)
{
add(new SongPanel(songs,new ResourceModel(songsInList,));
}
ComponentB.properties:
songsInList=50;
..
if you enable autolink, then this image-stuff could be much easier, so
the web design guy have much control and you have much OO as you can..
.. hope this will help a little
mm:)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Passing parameters from markup to panels
Thanks for those suggestions. I've actually got it kind of working
*with* an IComponentResolver and that seems to be working fine for now.
-Original Message-
From: Michael Mosmann [mailto:mich...@mosmann.de]
Sent: Thursday, 10 September 2009 6:24 PM
To: users@wicket.apache.org
Subject: RE: Passing parameters from markup to panels
Am Donnerstag, den 10.09.2009, 14:03 +1000 schrieb Chris Colman:
why? what is different between a 10 or a 50 item song panel? the
number
of items? you should anyhow use a ListView which repeats the her
is
the
song-block as many times as you want to..
It is using a ListView - the desire was to provide an easy way for
the
UI guy to specify a row count in the markup.
ok.. i got this.. i would put it into an property file of the
component
where the SongPanel is used and put a ResourceModel as parameter to
SongPanel
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.
why do you make this?
They each derive from SongChartTopPanel and invoke the constructor
with
a different row count - but without parameterization and using
standard
simple wicket devices (i.e. not component resolvers) then we need a
separate markup and separate .java class for each panel that has a
different number of songs displayed.
you can override getVariation to switch between markup.. so if you use
the ResourceModel for this, this should be easy..
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.
Yes but you'd still require a separate markup for each one I would
think
- without going the with component resolver approach.
i am not sure, that i understand this problem as it is.. so excuse, if
my solutions does not fit..
The web designer will have a nice 'Top 10' image above the panel so
I
didn't want to put it in the hands of the user who might change the
rowcount to 13 or something. 'Top 13 songs around the country this
week'
doesn't sound right - especially if the image above it says 'Top
10'.
ok..
some code to show you my view of this problem and the solution (may
not
fit)..
class SongPanel ..
{
SongPanel(String id,ResourceModel topCountAsStringModel)
{
final int count=getCountAsInt(topCountAsStringModel,10);
IModelSong model=new LoadabledDetachModel()
{
load() { ... getSongs(count) }
}
add(new ListView(songs,model) {..}
add(new Image(topImg,new ResourceReference(getClass(),
topImage,
getLocale(), top+count)))
}
getVariation()
{
return top+count;
}
}
SongPanel.html
wicket:panel
Top 10 (default)
img wicket:id=topImg
tabletr wicket:id=list.../table
/wicket:panel
SongPanel_top50.html
wicket:panel
Top 50
img wicket:id=topImg
tabletr wicket:id=list.../table
/wicket:panel
ComponentA(String id)
{
add(new SongPanel(songs,new ResourceModel(songsInList,));
}
ComponentA.properties:
songsInList=10;
ComponentB(String id)
{
add(new SongPanel(songs,new ResourceModel(songsInList,));
}
ComponentB.properties:
songsInList=50;
..
if you enable autolink, then this image-stuff could be much easier, so
the web design guy have much control and you have much OO as you can..
.. hope this will help a little
mm:)
-
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.86/2355 - Release Date:
09/10/09
05:50:00
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Passing parameters from markup to panels
Am Dienstag, den 08.09.2009, 09:10 +1000 schrieb Chris Colman:
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.
Ok.. maybe you can use this:
In your Panel you can use getString(EntriesInMyPanel) and convert this
to Integer. You have to put a EntriesInMyPanel=10 in you
MyPanel.properties-File, so that the web designer can change this,
without changing the code.
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 =)
You can not always express some changes to a display in a simple
Number.. especially in desktop development this could lead to a more
complex rule: show me as many songs as far the fit into the space used
by this component, but show at least 3 entries full and the rest in
compressed form. I did not see any simple number in this. So IMHO you
have to write code for this.
By the way.. maybe the best person to choose the right number is the
user.
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.
You can pass the Parameter into the Component as Parameter or as Model.
But IMHO there is no advantage for a static solution like putting it
into a markup- or a propertyfile.
.. and it's something
that directly affects the presentation side that he would want control
over. That gives him power.
because html is limited in a way, that this power is necessary
sometimes. but it's not a good idea. it's more a compromise.
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.
why? what is different between a 10 or a 50 item song panel? the number
of items? you should anyhow use a ListView which repeats the her is the
song-block as many times as you want to..
That's not OO and it's not reusability. It would be funny if
it wasn't true!
it is not true.. so i think you did not get the picture.. or we are
misunderstanding each other..
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.
why do you make this?
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.
class SongChartPanel
{
public SongChartPanel(String id,final int numberOfSongs)
{
LoadableDetachedModelListSong songs=new
LoadableDetachedModelListSong()
{
public ListSong load()
{
return Songs.getTopX(numberOfSongs);
}
}
add(new ListViewSong(list,songs)
{
public void populateItem(ListItemSong item)
{
item.add(new Label(name,item.getModelObject().getSongName()));
}
});
}
}
If you change numberOfSongs to a Model.. the User could change the
number (Form, Link,.. anything).
mm:)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Passing parameters from markup to panels
Chris Colman wrote: I've thought of a very ugly way of doing it with the current version of wicket but it relies on quite a lot of smoke and mirrors and hooking into the component creation process. I'll give that a go for now. We went a similar but still different way :) We use our own XML formatted files from which we render HTML, Swing, FOP, Excel... Because of this the designer can not only change the fields and their bindings but also parameters like rowcount in lists. Excellent! Similar to us with higher level XML (HTML) generating the wicket HTML. Cheers, Adrian - 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.86/2355 - Release Date: 09/09/09 17:50:00 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Passing parameters from markup to panels
why? what is different between a 10 or a 50 item song panel? the number of items? you should anyhow use a ListView which repeats the her is the song-block as many times as you want to.. It is using a ListView - the desire was to provide an easy way for the UI guy to specify a row count in the markup. 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. why do you make this? They each derive from SongChartTopPanel and invoke the constructor with a different row count - but without parameterization and using standard simple wicket devices (i.e. not component resolvers) then we need a separate markup and separate .java class for each panel that has a different number of songs displayed. 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. Yes but you'd still require a separate markup for each one I would think - without going the with component resolver approach. If you change numberOfSongs to a Model.. the User could change the number (Form, Link,.. anything). The web designer will have a nice 'Top 10' image above the panel so I didn't want to put it in the hands of the user who might change the rowcount to 13 or something. 'Top 13 songs around the country this week' doesn't sound right - especially if the image above it says 'Top 10'. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Passing parameters from markup to panels
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 Colmanchr...@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
Re: Passing parameters from markup to panels
each panel has to have a different wicket:id and the id should not exist in component hierarchy yet. component resolvers are only used if wicket cannot match wicket id to an object in the component hierarchy. -igor On Tue, Sep 8, 2009 at 5:51 AM, Chris Colmanchr...@stepaheadsoftware.com wrote: 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 Colmanchr...@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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Passing parameters from markup to panels
Chris Colman wrote: I've thought of a very ugly way of doing it with the current version of wicket but it relies on quite a lot of smoke and mirrors and hooking into the component creation process. I'll give that a go for now. We went a similar but still different way :) We use our own XML formatted files from which we render HTML, Swing, FOP, Excel... Because of this the designer can not only change the fields and their bindings but also parameters like rowcount in lists. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Passing parameters from markup to panels
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
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.comwrote:
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
RE: Passing parameters from markup to panels
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.comwrote:
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
Re: Passing parameters from markup to panels
It could be done. I'm pretty sure that if you used onComponentTag (can't
remember exact name this second - and just walking out the door) - you could
read any attribute from the tag. Then hold that number in your component
and let your model that reads the songs read that number to determine how
many.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Sep 7, 2009 at 6:10 PM, Chris Colman
chr...@stepaheadsoftware.comwrote:
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.comwrote:
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
Re: Passing parameters from markup to panels
You don't need multiple versions of the panel, you simply need a constructor
that takes an argument, the number of items you want to include. This
doesn't fully fulfill your use case as your site-devs or portal-devs cannot
pass that argument in.
You could arrange that using iframes and passed parameters.
Ed.
On Mon, Sep 7, 2009 at 7:10 PM, Chris Colman
chr...@stepaheadsoftware.comwrote:
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.comwrote:
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
Re: Passing parameters from markup to panels
Slight problem here is that onComponentTag is called during render.
You can't modify component hierarchy at that point.
Only way around this is to find component's markup index in
onBeforeRender and then get the tag from markup stream. But this will
fail in many cases (borders, transparent resolvers). So it's not a
very good way.
-Matej
On Tue, Sep 8, 2009 at 1:38 AM, Jeremy
Thomersonjer...@wickettraining.com wrote:
It could be done. I'm pretty sure that if you used onComponentTag (can't
remember exact name this second - and just walking out the door) - you could
read any attribute from the tag. Then hold that number in your component
and let your model that reads the songs read that number to determine how
many.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Sep 7, 2009 at 6:10 PM, Chris Colman
chr...@stepaheadsoftware.comwrote:
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.comwrote:
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
Re: Passing parameters from markup to panels
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
Colmanchr...@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.comwrote:
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
RE: Passing parameters from markup to panels
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
Re: Passing parameters from markup to panels
Then why not just create a configuration panel so your designer can configure the number of items to display? On Sep 8, 2009, at 9:23 AM, Chris Colman 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
RE: Passing parameters from markup to panels
Then why not just create a configuration panel so your designer can configure the number of items to display? Scenario: Let's say 8 different pages use the same SongChartPanel and each wants to list a different number of songs. Providing a configuration panel for the web designer to configure a 'count' value for each instance where the panel is used is more work and it adds presentation domain stuff to the database. It also has the requirement of associating the 'count' parameter with each 'usage' of the panel in the model. Whenever they want to add another panel to a markup a new configuration property needs to be made available for configuration in the configuration panel and somehow specify 'which' panel instance in 'which' markup they are configuring. Seems much more simple and quicker and more MVC if they could simply specify that presentation oriented information right there in the presentation layer (markup) in which they use the instance: span wicket:id=songChartPanel wicket:attr=count=50 / I've thought of a very ugly way of doing it with the current version of wicket but it relies on quite a lot of smoke and mirrors and hooking into the component creation process. I'll give that a go for now. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Passing parameters from markup to panels
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 Colmanchr...@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
RE: Passing parameters from markup to panels
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 Colmanchr...@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
Re: Passing parameters from markup to panels
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 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.comwrote: 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 Colmanchr...@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
RE: Passing parameters from markup to panels
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.comwrote: 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 Colmanchr...@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
RE: Passing parameters from markup to panels
I'm doing some experimenting with ComponentTag.getAttributes() - it
looks
like the one!!
Doh! It doesn't seem to work. No matter how many attributes I add to the
tag and no matter whether I add the wicket: namespace to them or not I
only ever see the single wicket:id attribute when I run this code in the
IComponentResolver.resolve method:
tag is the ComponentTag passed into the resolve method by wicket.
Set atSet = tag.getAttributes().keySet();
Iterator ai = atSet.iterator();
while (ai.hasNext())
{
logger.trace(key = + ai.next());
}
Any ideas on what I'm doing wrong.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Passing parameters from markup to panels
-Original Message- Doh! It doesn't seem to work. ... Whoops! Please ignore the above! It works like a charm when you place the parameters in the right place ;) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Passing parameters from markup to panels
thats pretty strange, create a unit test and we will fix it. -igor On Mon, Sep 7, 2009 at 9:00 PM, Chris Colmanchr...@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.comwrote: 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 Colmanchr...@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,
