@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 <[email protected]> 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 <[email protected]>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 <[email protected]
>> >wrote:
>>
>> > I like that idea!
>> >
>> >
>> > On Tue, May 26, 2009 at 10:33 AM, Igor Vaynberg <
>> [email protected]
>> > >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
>> > > <[email protected]> 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 <
>> [email protected]>
>> > > wrote:
>> > > >> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
>> > > >> [email protected]> 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: [email protected]
>> > > > For additional commands, e-mail: [email protected]
>> > > >
>> > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [email protected]
>> > > For additional commands, e-mail: [email protected]
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Regards,
>> Vasu Srinivasan
>>
>
>
