@Luther:
Yes - I'm using the ImageButton it to submit a form.
Thanks for the suggestion to use the modifier. I will try that.
On a side note, I thought that having the images/css/js etc served from
webserver is pretty common and would be supported by wicket without having
to add the names within java code.
I understand the reasoning behind using new ResourceReference as it makes
loading locale specific images very simple. But why should wicket prepend
classpath etc. -- i'm not clear on that. Can't wicket simply ignore the
"src" attribute if ResourceReference is not present and use whatever was
already in the html template? That way I do not have to specify the image
name within the java code and the separation between java and html is clean.
On 5/26/09, Luther Baker <lutherba...@gmail.com> wrote:
>
> @Vasu
>
> Try overriding the "*src*" attribute with a SimpleAttributeModifier :-)
> You'll need to manage your static paths in Java (Constants.IMG_PATH ...
> etc)
> ... but it works as expected:
>
> final ImageButton submit = new ImageButton("i-thunder");
> submit.add(new SimpleAttributeModifier("src",
> "img/thunder_medium.jpg"));
>
> *results in*
>
> <input type="image" wicket:id="i-thunder"
> *src=**"img/thunder_medium.jpg"* name="i-thunder" id="i_thunder2f"/>
>
> *instead of*
>
> <input type="image" wicket:id="i-thunder"
>
> src="resources/org.effectiveprogramming.effprog.web.markup.page.Contact/img/thunder_medium_en_US.jpg"
> name="i-thunder" id="i_thunder31"/>
>
>
>
> -Luther
>
>
>
>
> On Tue, May 26, 2009 at 9:13 PM, Luther Baker <lutherba...@gmail.com>
> wrote:
>
> > You may have to look at this case by case ...
> >
> > In this example, what are you doing with the input field? Submitting a
> > form?
> >
> > Were that the case, how about using a raw input tag and moving any wicket
> > logic to the submit handler?
> >
> > -Luther
> >
> >
> >
> >
> >
> > On Tue, May 26, 2009 at 6:02 PM, Vasu Srinivasan <vasy...@gmail.com
> >wrote:
> >
> >> I too have been trying to find the right way about where to put the
> >> resources (image, css, js). I work in an environment where the
> >> images/css/js
> >> are maintained by a separate team and is in apache server as they are
> >> reused
> >> across several apps/projects in different app servers. So putting it as
> >> part
> >> of the application is a no-no (src/main/resources or src/main/webapp
> etc.)
> >> .
> >> It doesn't work that way though -- I tried using a ImageButton without
> >> passing the new ResourceReference() in the constructor.
> >>
> >> My html is like:
> >>
> >> <input type="image" wicket:id="imageId" src="/images/button.gif" />
> >>
> >> Wicket replaces the html with <input type="image"
> >> src="resources/.....//images/button.gif" /> and obviously does not find
> >> it.
> >>
> >> Is there a clean way out of this? (ie not prepend resources/... etc)
> >>
> >> Thanks!
> >> Vasya
> >>
> >>
> >> On Tue, May 26, 2009 at 12:40 PM, Luther Baker <lutherba...@gmail.com
> >> >wrote:
> >>
> >> > I like that idea!
> >> >
> >> >
> >> > On Tue, May 26, 2009 at 10:33 AM, Igor Vaynberg <
> >> igor.vaynb...@gmail.com
> >> > >wrote:
> >> >
> >> > > it may be helpful to create <wicket:context> analog of
> <wicket:link>,
> >> > > we already have the framework for getting the path prefix to get to
> >> > > context path.
> >> > >
> >> > > this is of course only useful for application-specific resources as
> >> > > those will not be reused across projects. in our case our SA
> extracts
> >> > > the war and copies everything but WEB-INF to apache so all those
> >> > > static application resources can be served there.
> >> > >
> >> > > -igor
> >> > >
> >> > > On Tue, May 26, 2009 at 2:41 AM, Martijn Dashorst
> >> > > <martijn.dasho...@gmail.com> wrote:
> >> > > > Why wouldn't it be a viable solution? It gives you the opportunity
> >> to
> >> > > > let the resources be served by your container, which should be
> >> > > > speedier than letting wicket handle it (such requests are filtered
> >> > > > through and go to your container).
> >> > > >
> >> > > > The relative paths are just that: relative, and they always map to
> >> the
> >> > > > absolute same resource URI. In fact, they are more stable than
> >> serving
> >> > > > things from your classpath, as those resources are served from the
> >> > > > path /context/resources/...., and if we decide to call that path
> >> > > > /context/foobar/.... all your reasoning about stability goes out
> the
> >> > > > window.
> >> > > >
> >> > > > Martijn
> >> > > >
> >> > > > On Mon, May 25, 2009 at 6:38 PM, Luther Baker <
> >> lutherba...@gmail.com>
> >> > > wrote:
> >> > > >> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
> >> > > >> martijn.dasho...@gmail.com> wrote:
> >> > > >>
> >> > > >>> or, if these images and css are for your application, and
> >> application
> >> > > >>> wide (i.e. all pages include them), you could put them in
> >> > > >>> src/main/webapp/......
> >> > > >>>
> >> > > >>> and just <link src="style.css" ... /> them in your markup.
> >> > > >>>
> >> > > >>> Martijn
> >> > > >>>
> >> > > >>
> >> > > >> I'd like to pose a design/theoratical thought here ....
> >> > > >>
> >> > > >> I understand that <wicket:link/> does the right thing for
> resources
> >> > > (like
> >> > > >> stylesheets) kept in the classpath. I love this behavior.
> >> > > >>
> >> > > >> But, as we know, depending on where my browser URL points, the
> >> > > following:
> >> > > >>
> >> > > >> <link href="css/styles.css" .../>
> >> > > >>
> >> > > >> resolves to different locations. For instance, said stylesheet
> >> > > referenced
> >> > > >> from:
> >> > > >>
> >> > > >> http://hostname/context/products/wires/24
> >> > > >>
> >> > > >> physically resolves to (mavenized)
> >> > > webapps/*products/wires*/css/styles.css,
> >> > > >> whereas from
> >> > > >>
> >> > > >> http://hostname/context/people/hr/judy
> >> > > >>
> >> > > >> resolves to webapps/*people/hr/judy*/css/styles.css
> >> > > >>
> >> > > >> (In part, this is due to our effort NOT to hardcode the context
> >> into
> >> > the
> >> > > >> link's href.)
> >> > > >>
> >> > > >> *Traditionally, I solved this one of three ways:*
> >> > > >>
> >> > > >> 1. Manually manage every application URL and every mapped file
> >> and
> >> > > make
> >> > > >> sure that in all cases the relative path is correct. Ugh! For
> >> > obvious
> >> > > >> reasons - this technique is not maintainable. Large apps back
> in
> >> the
> >> > > early
> >> > > >> days of Struts with hundreds of actions and JSPs, this just
> >> wasn't
> >> > > fun.
> >> > > >> 2. JSTL came along and I started to leverage the <c:url tag.
> For
> >> the
> >> > > most
> >> > > >> part, that was a workable solution - the resulting path was
> >> > 'absolute'
> >> > > but
> >> > > >> it wasn't hardcoded. Essentially, it gives the framework a
> chance
> >> to
> >> > > work
> >> > > >> its magic (if it were to change somehow).
> >> > > >> 3. Today, I use the resource method (<wicket:link/>) which
> >> obviates
> >> > > all
> >> > > >> anxiety by simply letting the framework just manage it.
> >> > > >>
> >> > > >> So to your point Martijn, is using webapp/css and directly
> >> including
> >> > > <link
> >> > > >> href="css/styles.css" .../> really a good - viable, long-term
> >> solution
> >> > > in
> >> > > >> Wicket apps? Understandably maybe today, the default URL mapper
> in
> >> > > Wicket
> >> > > >> uses query strings and not deep or hierarchical urls - but the
> >> > important
> >> > > >> term for me here is "today".
> >> > > >>
> >> > > >> What if, in the future, wicket decides to change the default URL
> >> > mapping
> >> > > >> scheme - maybe become more RESTful. The inertia built up around
> >> legacy
> >> > > apps
> >> > > >> using webapp/css may pose a problem. I don't think this is
> >> premature
> >> > > >> functionality ... I think links and urls are a here a now thing
> and
> >> > that
> >> > > >> building and migrating apps to future versions of frameworks is
> >> hard
> >> > and
> >> > > >> that a loose practice here may come back to bite a developer ...
> ?
> >> > > >>
> >> > > >> Also, I've not yet mounted urls but I assume if I were to mount
> >> URLs -
> >> > > I'd
> >> > > >> have to really manage this webapp/css approach - whereas, the
> >> resource
> >> > > >> approach with <wicket:link/> would just keep humming along.
> >> > > >>
> >> > > >> Some may argue that it isn't really *better* to provide multiple
> >> ways
> >> > to
> >> > > do
> >> > > >> the same thing ... take Tapestry for instance and the technical
> >> > > relevance as
> >> > > >> to where markup files can or cannot reside.
> >> > > >>
> >> > > >> This post is indeed a bit philosophical/theoretical - I've often
> >> > thought
> >> > > >> about this topic and wanted to clarify in my mind that maybe,
> these
> >> > are
> >> > > >> either moot points, ignored concerns, overthinking on my part ...
> >> or
> >> > > just
> >> > > >> not important somehow. As I mentioned, this little detail has
> >> always
> >> > > been a
> >> > > >> pain point in my previous work and I've just been happy as a lark
> >> to
> >> > use
> >> > > the
> >> > > >> <wicket:link/> which protects me from whatever the future
> provides.
> >> > I'm
> >> > > just
> >> > > >> surprised it isn't the suggested best practice or that dropping
> >> files
> >> > > into
> >> > > >> webapp/* is *ill*-advised since it assumes something about how
> >> Wicket
> >> > > works.
> >> > > >>
> >> > > >> Thanks,
> >> > > >>
> >> > > >> -Luther
> >> > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Become a Wicket expert, learn from the best:
> >> http://wicketinaction.com
> >> > > > Apache Wicket 1.3.5 is released
> >> > > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > 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
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Vasu Srinivasan
> >>
> >
> >
>
--
Regards,
Vasu Srinivasan
