You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Lucas Bonansea <lu...@gmail.com> on 2009/05/24 04:10:32 UTC
Storing css and image files
Hello.
I'm new to web development and to Wicket. I created an Wicket
project in Eclipse following the instructions in the website, from there and
following the examples I have been able to create a couple of simple web
pages. The problem I am having, is that I don't know where to store my css
file and my image files so that they would be loaded when I execute my new
web pages.
If possible I would like to do it using relative paths so then I
can deploy my war elsewhere
Thanks
Lucas B
Re: Storing css and image files
Posted by Per Lundholm <pe...@gmail.com>.
Check out the tag <wicket:link>
/Per
2009/5/24 Lucas Bonansea <lu...@gmail.com>:
> Hello.
> I'm new to web development and to Wicket. I created an Wicket
> project in Eclipse following the instructions in the website, from there and
> following the examples I have been able to create a couple of simple web
> pages. The problem I am having, is that I don't know where to store my css
> file and my image files so that they would be loaded when I execute my new
> web pages.
> If possible I would like to do it using relative paths so then I
> can deploy my war elsewhere
>
> Thanks
>
> Lucas B
>
--
FaceBush, min insamling i Mustaschkampen:
http://www.cancerfonden.se//sv/Mustaschkampen/Kampa/Insamlingar/?collection=243
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
Where's the edit button :)
Near the beginning,
"theoratical" should be theoretical.
Near the end,
"I'm just surprised ... that dropping files into webapp/* is
*ill*-advised"
should read
"I'm just surprised ... that dropping files into webapp/* isn't *ill
*-advised"
I'm sure there are more. Thanks,
-Luther
On Mon, May 25, 2009 at 11:38 AM, Luther Baker <lu...@gmail.com>wrote:
> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
> martijn.dashorst@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
>
>
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
On Tue, May 26, 2009 at 4:41 AM, Martijn Dashorst <
martijn.dashorst@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).
Yep.
> The relative paths are just that: relative, and they always map to the
> absolute same resource URI.
I think I'm missing something here. If one uses the regular webapp location
to storee css, as I mentioned, http://localhost/a/b requesting
css/styles.css will request a different file than
http://localhost/a/NOTbrequesting the same css/styles.css.
Relative paths will NOT map to the same absolute resource URI. IN the first
example, the file webapps/a/b/css/styles.css is retrieved. In the second
example, webapp/a/NOTb/css/styles.css is retrieved. In both files, I've used
the <link href="css/styles.css" ...
> 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.
Ahh .... I thought quite the opposite. If I have files
src/main/java/a/b/Page.java
src/main/resources/a/b/Page.html
src/main/resources/a/b/css/styles.css
and Page.html includes this:
<wicket:link>
<link rel="stylesheet" type="text/css"
href="css/standard/common.css" />
<link rel="stylesheet" type="text/css"
href="css/standard/header.css" />
</wicket:link>
it turns into this:
<link rel="stylesheet" type="text/css"
href="resources/org.effectiveprogramming.effprog.web.markup.layout.BasicLayout/css/standard/common.css"/>
which always works. In my eyes, I am giving Wicket just enought information
to find my css files. How Wicket decides to encode the <wicket:link/> code
is none of my business. As long as the contract is adhered to. I give it a
very small relative link path in my resources hierarchy and Wicket encodes
that and will ALWAYS find it.
If Wicket decides to change how <wicket:link/> encodes a resource (changes
/context/resources to /context/foobar/) that is fine with me - as long as
Wicket keeps reading in the resources correctly. You imply that, given my
aforemetioned files,
<wicket:link>
<link rel="stylesheet" type="text/css"
href="css/standard/common.css" />
<link rel="stylesheet" type="text/css"
href="css/standard/header.css" />
</wicket:link>
would break if Wicket changed /context/resources to /context/foobar ... and
thats not what I expected.
I complete agree with the 'performance' point ... and maybe I just
misundertstand your perspective but directly using the
<link rel="stylesheet" type="text/css"
href="css/standard/common.css" />
and fetching pages from webapp/ seems much more volatile to me than using
<wicket:link>
<link rel="stylesheet" type="text/css"
href="css/standard/common.css" />
</wicket:link>
which will be encoded however wicket pleases and always served up from a
path relative to the resource including it.
-Luther
I don't code /context/resources
>
>
> Martijn
>
> On Mon, May 25, 2009 at 6:38 PM, Luther Baker <lu...@gmail.com>
> wrote:
> > **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
> > martijn.dashorst@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
>
> The clean way in my case is as Steve suggested , to use css to display the
> image for button.
Thanks for all the inputs. Sorry this has dragged out a bit.
In my case, I am not sharing static resources across apps. I'm just looking
at the best way for each page in my application to retrieve each of the
core, application-wide, application-specific, static resource files (js,
css, gif, jpg, etc). I might have common.css, header.css, footer.css. Maybe
that falls under "keep it with the source" -- which works just fine / albeit
somewhat limiting.
So maybe the point is moot and <wicket:link/> is the solution for my case. I
think physically dropping files in webapp/**/*.css is just fine. I'm really
just suggesting the idea of making a robust, infallible way to refer to them
that can be written and included just once (in an abstract BaseLayoutPage)
and never talked about again :) ... and was entertaining the idea of using
the webapp/ directory for this.
The suggested IHeaderContributor solution has a few problems in my case. If
a developer adds a page 6 mos from now and mounts it to a new, arbitrary
URL, */products/cable/offer* - I'd like the css files to all show up -
automatically. Unfortunately, IHeaderContributor will not dynamically refer
to the original css/styles.css pages. The paths are just echo'd as entered
which means ... the single css isn't found.
My other made up example - if Wicket (for whatever reason) decides that 1.5
should default to RESTful URLs, would also break anywhere people were
hardcoding <link href="css/styles.css" ... since the new RESTful URLs
wouldn't look in the proper location.
On the other hand, <wicket:link/> continues to work through all of these
changes - with no effort or manual management.
My initial posts/examples were around <c:url value="/css/styles.css"/> when
included on base base pages, always works no matter what page the user has
navigated to ... no matter how deep or shallow the url is. It creates an
ABSOLUTE path that simply prepends the context the app is deployed to
(which, is free to change or go to root).
For what its worth, I think that provides some amount of value to my app.
For my specific case, I think Igor's suggestion of a tag like
<wicket:context/> hit the nail on the head. I can't tell if the other
suggestions here are just workarounds or really trying to address my
specific use case. IHeaderContribute (thanks for including) doesn't actually
do much more than hardcode a fixed path in the markup.
Incidentally, I looked - and man, there are alot of pieces to <wicket:link/>
:-) Is there an online tutorial for, not just writing components, but
implementing a markup component like <wicket:link/>?
Ahhhh ... thanks,
-Luther
Re: Storing css and image files
Posted by Vasu Srinivasan <va...@gmail.com>.
I went thru the thread to understand the context. I agree with
html/java/properties being together, i do not have issues with that. If I
have a standalone app, I will have no issues putting css /js in the
src/main/webapp.
But its the reusability of js/css/images across several projects is whats
bothering me. I think adding javacode like imageButton.add(new
SimpleAttributeModifier("src", "/images/continue.gif")) for each and every
page is superfluous. I can minimize the impact several ways (Constants.IMAGE
path or building a Continue Image button etc), but I still think the Java
code should not need to know about the name of the image and where it is
located (classpath or apache webserver). The imagebutton is just responding
to an event related to the wicket:id, where its srced from is the
responsibility of the template.
Ideally the location where the image is sourced from could be left to
template, while the image file name itself could be generated by Wicket
based on locale.
The clean way in my case is as Steve suggested , to use css to display the
image for button.
On Wed, May 27, 2009 at 8:41 AM, Luther Baker <lu...@gmail.com> wrote:
> Admittedly, I think this is slightly out of context here ... but a few days
> back, Martijn posted (no bashing intended - I try to adhere to this):
>
>
> "There is no sane reason why anyone would put the html, js, css and
> properties resources in any place except *next* to the
> corresponding.java file. Your .java file can not function without the
> .html file. Your component will fail if the .properties file is not
> available. When the js file can't be found your component is useless.
>
> Wicket goes beyond the call of duty to provide developers with the
> means to encapsulate your components, bringing Object Oriented design
> and programming to the web tier. Moving the necessary resources
> outside the package folder into a separate directory structure breaks
> this encapsulation is definitely not the Wicket Way (tm)."
>
> http://osdir.com/ml/users-wicket.apache.org/2009-03/msg01100.html
>
>
>
>
> On Wed, May 27, 2009 at 8:36 AM, Luther Baker <lu...@gmail.com>
> wrote:
>
> > Hi Steve,
> >
> > Continue your example and mount a url to an existing page that extends
> > BasePage:
> >
> > mountBookmarkablePage("/im/going/home", About.class);
> >
> > and tell me what happens to your js and css references when you visit
> that
> > url.
> >
> > Hope that helps,
> >
> > -Luther
> >
> >
> >
> > On Wed, May 27, 2009 at 7:20 AM, Steve Swinsburg <
> > s.swinsburg@lancaster.ac.uk> wrote:
> >
> >> I don't see the issue that you all seem to be experiencing but I can
> offer
> >> some advice:
> >> CSS, Javascript, images etc should be stored in the webapp directory NOT
> >> mixed in with the rest of the classes and HTML. Your CSS can then get at
> >> them easily if you are using any background images etc. Martijn
> mentioned
> >> this and its a valid point, you can then unmount the directories and let
> the
> >> web server serve them statically rather than Tomcat serve them which
> takes
> >> up threads.
> >>
> >> You can use an IHeaderContributor to add any CSS or Javascript
> references
> >> into the HTML header:
> >>
> >> public class BasePage extends WebPage implements IHeaderContributor {
> >>
> >> public void renderHead(IHeaderResponse response) {
> >>
> response.renderCSSReference("css/jquery.cluetip.css");response.renderJavascriptReference(
> >> "javascript/jquery.dimensions.js");
> >> response.renderJavascriptReference("javascript/jquery.hoverIntent.js");
> >> response.renderJavascriptReference("javascript/jquery.cluetip.js");
> >> }
> >>
> >> If you need to add any images in your page, use a ContextImage which is
> >> relative to the context always.
> >>
> >> I tend to use a BasePage which setups the header and have my other pages
> >> extend BasePage you might find it useful as well.
> >>
> >>
> >> cheers,
> >> Steve
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 27 May 2009, at 06:40, Luther Baker wrote:
> >>
> >> On Tue, May 26, 2009 at 11:43 PM, Vasu Srinivasan <va...@gmail.com>
> >> wrote:
> >>
> >> @Luther:
> >>
> >>
> >> Yes - I'm using the ImageButton it to submit a form.
> >>
> >>
> >> Thanks for the suggestion to use the modifier. I will try that.
> >>
> >>
> >>
> >> Great. I think it should work for you.
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> If I had to guess ... it is probably just a matter of time. There are
> >> probably a lot of design and "Wicket Way" considerations the team
> iterates
> >> through and prioritizes. I think cases like yours bring some of these
> >> usage
> >> points into clearer focus after-which, maybe they'll get some traction.
> >>
> >> My guess is that these folks are pretty busy and that there are probably
> >> 10s
> >> of 100s of similar requests in the queue - so just need some time ... or
> >> bodies :)
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> It sounds reasonable to me - but I'm not knee deep in the code
> either/yet.
> >>
> >> -Luther
> >>
> >>
> >>
> >
>
--
Regards,
Vasu Srinivasan
Re: Storing css and image files
Posted by Steve Swinsburg <s....@lancaster.ac.uk>.
CSS could still take care of this if your CSS could handle all the
images, included via the IHeaderContributor and then you don't need to
mix the display with the code.
Or setup some constants that take the main prefix to the common
repository so at least you only need to change it in one spot, not
everywhere the images etc are being used.
cheers,
Steve
On 27 May 2009, at 14:21, Vasu Srinivasan wrote:
> @Steve
>
>>> NOT mixed in with the rest of the classes and HTML.
>
> i totally agree with that.
>
>>> CSS, Javascript, images etc should be stored in the webapp directory
>
> my point is this may not be the case for all. in a big company i
> worked
> before, the css and continue/reset/submit/go buttons etc are stored
> in a
> central repository and had to be src-ed from there. Noway i could
> copy and
> put them into webapp. Now referencing them in my java code would
> mean that
> any change (say new image version) would have to be done within java
> instead
> of just having to change the template.
>
> thanks!
> vasya
>
>
> On Wed, May 27, 2009 at 7:20 AM, Steve Swinsburg <
> s.swinsburg@lancaster.ac.uk> wrote:
>
>> I don't see the issue that you all seem to be experiencing but I
>> can offer
>> some advice:
>> CSS, Javascript, images etc should be stored in the webapp
>> directory NOT
>> mixed in with the rest of the classes and HTML. Your CSS can then
>> get at
>> them easily if you are using any background images etc. Martijn
>> mentioned
>> this and its a valid point, you can then unmount the directories
>> and let the
>> web server serve them statically rather than Tomcat serve them
>> which takes
>> up threads.
>>
>> You can use an IHeaderContributor to add any CSS or Javascript
>> references
>> into the HTML header:
>>
>> public class BasePage extends WebPage implements IHeaderContributor {
>>
>> public void renderHead(IHeaderResponse response) {
>> response.renderCSSReference("css/jquery.cluetip.css");
>> response.renderJavascriptReference("javascript/
>> jquery.dimensions.js");
>> response.renderJavascriptReference("javascript/
>> jquery.hoverIntent.js");
>> response.renderJavascriptReference("javascript/jquery.cluetip.js");
>> }
>>
>> If you need to add any images in your page, use a ContextImage
>> which is
>> relative to the context always.
>>
>> I tend to use a BasePage which setups the header and have my other
>> pages
>> extend BasePage you might find it useful as well.
>>
>>
>> cheers,
>> Steve
>>
>>
>>
>>
>>
>>
>> On 27 May 2009, at 06:40, Luther Baker wrote:
>>
>> On Tue, May 26, 2009 at 11:43 PM, Vasu Srinivasan <va...@gmail.com>
>> wrote:
>>
>> @Luther:
>>
>>
>> Yes - I'm using the ImageButton it to submit a form.
>>
>>
>> Thanks for the suggestion to use the modifier. I will try that.
>>
>>
>>
>> Great. I think it should work for you.
>>
>>
>>
>> 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.
>>
>>
>>
>> If I had to guess ... it is probably just a matter of time. There are
>> probably a lot of design and "Wicket Way" considerations the team
>> iterates
>> through and prioritizes. I think cases like yours bring some of
>> these usage
>> points into clearer focus after-which, maybe they'll get some
>> traction.
>>
>> My guess is that these folks are pretty busy and that there are
>> probably
>> 10s
>> of 100s of similar requests in the queue - so just need some
>> time ... or
>> bodies :)
>>
>>
>> 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.
>>
>>
>>
>> It sounds reasonable to me - but I'm not knee deep in the code
>> either/yet.
>>
>> -Luther
>>
>>
>>
>
>
> --
> Regards,
> Vasu Srinivasan
Re: Storing css and image files
Posted by Vasu Srinivasan <va...@gmail.com>.
@Steve
>> NOT mixed in with the rest of the classes and HTML.
i totally agree with that.
>> CSS, Javascript, images etc should be stored in the webapp directory
my point is this may not be the case for all. in a big company i worked
before, the css and continue/reset/submit/go buttons etc are stored in a
central repository and had to be src-ed from there. Noway i could copy and
put them into webapp. Now referencing them in my java code would mean that
any change (say new image version) would have to be done within java instead
of just having to change the template.
thanks!
vasya
On Wed, May 27, 2009 at 7:20 AM, Steve Swinsburg <
s.swinsburg@lancaster.ac.uk> wrote:
> I don't see the issue that you all seem to be experiencing but I can offer
> some advice:
> CSS, Javascript, images etc should be stored in the webapp directory NOT
> mixed in with the rest of the classes and HTML. Your CSS can then get at
> them easily if you are using any background images etc. Martijn mentioned
> this and its a valid point, you can then unmount the directories and let the
> web server serve them statically rather than Tomcat serve them which takes
> up threads.
>
> You can use an IHeaderContributor to add any CSS or Javascript references
> into the HTML header:
>
> public class BasePage extends WebPage implements IHeaderContributor {
>
> public void renderHead(IHeaderResponse response) {
> response.renderCSSReference("css/jquery.cluetip.css");
> response.renderJavascriptReference("javascript/jquery.dimensions.js");
> response.renderJavascriptReference("javascript/jquery.hoverIntent.js");
> response.renderJavascriptReference("javascript/jquery.cluetip.js");
> }
>
> If you need to add any images in your page, use a ContextImage which is
> relative to the context always.
>
> I tend to use a BasePage which setups the header and have my other pages
> extend BasePage you might find it useful as well.
>
>
> cheers,
> Steve
>
>
>
>
>
>
> On 27 May 2009, at 06:40, Luther Baker wrote:
>
> On Tue, May 26, 2009 at 11:43 PM, Vasu Srinivasan <va...@gmail.com>
> wrote:
>
> @Luther:
>
>
> Yes - I'm using the ImageButton it to submit a form.
>
>
> Thanks for the suggestion to use the modifier. I will try that.
>
>
>
> Great. I think it should work for you.
>
>
>
> 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.
>
>
>
> If I had to guess ... it is probably just a matter of time. There are
> probably a lot of design and "Wicket Way" considerations the team iterates
> through and prioritizes. I think cases like yours bring some of these usage
> points into clearer focus after-which, maybe they'll get some traction.
>
> My guess is that these folks are pretty busy and that there are probably
> 10s
> of 100s of similar requests in the queue - so just need some time ... or
> bodies :)
>
>
> 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.
>
>
>
> It sounds reasonable to me - but I'm not knee deep in the code either/yet.
>
> -Luther
>
>
>
--
Regards,
Vasu Srinivasan
Re: Storing css and image files
Posted by Martijn Dashorst <ma...@gmail.com>.
This only refers to component (page) specific resources. Not global
resources for your application. If you want to create reusable
components/pages that you can share between projects, then they need
to be on the classpath. If you have a app specific CSS that you
include from your app specific BasePage, there is no reason not to put
it in src/webapp/style.css (similar for javascript files, e.g. a
minimized jquery.js that is concatenated with your global app specific
js files, to minimize the number of connects to your server)
As with any rule: use that gray matter locked between your ears and
common sense!
Martijn
On Wed, May 27, 2009 at 3:41 PM, Luther Baker <lu...@gmail.com> wrote:
> Admittedly, I think this is slightly out of context here ... but a few days
> back, Martijn posted (no bashing intended - I try to adhere to this):
>
>
> "There is no sane reason why anyone would put the html, js, css and
> properties resources in any place except *next* to the
> corresponding.java file. Your .java file can not function without the
> .html file. Your component will fail if the .properties file is not
> available. When the js file can't be found your component is useless.
>
> Wicket goes beyond the call of duty to provide developers with the
> means to encapsulate your components, bringing Object Oriented design
> and programming to the web tier. Moving the necessary resources
> outside the package folder into a separate directory structure breaks
> this encapsulation is definitely not the Wicket Way (tm)."
>
> http://osdir.com/ml/users-wicket.apache.org/2009-03/msg01100.html
>
>
>
>
> On Wed, May 27, 2009 at 8:36 AM, Luther Baker <lu...@gmail.com> wrote:
>
>> Hi Steve,
>>
>> Continue your example and mount a url to an existing page that extends
>> BasePage:
>>
>> mountBookmarkablePage("/im/going/home", About.class);
>>
>> and tell me what happens to your js and css references when you visit that
>> url.
>>
>> Hope that helps,
>>
>> -Luther
>>
>>
>>
>> On Wed, May 27, 2009 at 7:20 AM, Steve Swinsburg <
>> s.swinsburg@lancaster.ac.uk> wrote:
>>
>>> I don't see the issue that you all seem to be experiencing but I can offer
>>> some advice:
>>> CSS, Javascript, images etc should be stored in the webapp directory NOT
>>> mixed in with the rest of the classes and HTML. Your CSS can then get at
>>> them easily if you are using any background images etc. Martijn mentioned
>>> this and its a valid point, you can then unmount the directories and let the
>>> web server serve them statically rather than Tomcat serve them which takes
>>> up threads.
>>>
>>> You can use an IHeaderContributor to add any CSS or Javascript references
>>> into the HTML header:
>>>
>>> public class BasePage extends WebPage implements IHeaderContributor {
>>>
>>> public void renderHead(IHeaderResponse response) {
>>> response.renderCSSReference("css/jquery.cluetip.css");response.renderJavascriptReference(
>>> "javascript/jquery.dimensions.js");
>>> response.renderJavascriptReference("javascript/jquery.hoverIntent.js");
>>> response.renderJavascriptReference("javascript/jquery.cluetip.js");
>>> }
>>>
>>> If you need to add any images in your page, use a ContextImage which is
>>> relative to the context always.
>>>
>>> I tend to use a BasePage which setups the header and have my other pages
>>> extend BasePage you might find it useful as well.
>>>
>>>
>>> cheers,
>>> Steve
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 27 May 2009, at 06:40, Luther Baker wrote:
>>>
>>> On Tue, May 26, 2009 at 11:43 PM, Vasu Srinivasan <va...@gmail.com>
>>> wrote:
>>>
>>> @Luther:
>>>
>>>
>>> Yes - I'm using the ImageButton it to submit a form.
>>>
>>>
>>> Thanks for the suggestion to use the modifier. I will try that.
>>>
>>>
>>>
>>> Great. I think it should work for you.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> If I had to guess ... it is probably just a matter of time. There are
>>> probably a lot of design and "Wicket Way" considerations the team iterates
>>> through and prioritizes. I think cases like yours bring some of these
>>> usage
>>> points into clearer focus after-which, maybe they'll get some traction.
>>>
>>> My guess is that these folks are pretty busy and that there are probably
>>> 10s
>>> of 100s of similar requests in the queue - so just need some time ... or
>>> bodies :)
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> It sounds reasonable to me - but I'm not knee deep in the code either/yet.
>>>
>>> -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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
Admittedly, I think this is slightly out of context here ... but a few days
back, Martijn posted (no bashing intended - I try to adhere to this):
"There is no sane reason why anyone would put the html, js, css and
properties resources in any place except *next* to the
corresponding.java file. Your .java file can not function without the
.html file. Your component will fail if the .properties file is not
available. When the js file can't be found your component is useless.
Wicket goes beyond the call of duty to provide developers with the
means to encapsulate your components, bringing Object Oriented design
and programming to the web tier. Moving the necessary resources
outside the package folder into a separate directory structure breaks
this encapsulation is definitely not the Wicket Way (tm)."
http://osdir.com/ml/users-wicket.apache.org/2009-03/msg01100.html
On Wed, May 27, 2009 at 8:36 AM, Luther Baker <lu...@gmail.com> wrote:
> Hi Steve,
>
> Continue your example and mount a url to an existing page that extends
> BasePage:
>
> mountBookmarkablePage("/im/going/home", About.class);
>
> and tell me what happens to your js and css references when you visit that
> url.
>
> Hope that helps,
>
> -Luther
>
>
>
> On Wed, May 27, 2009 at 7:20 AM, Steve Swinsburg <
> s.swinsburg@lancaster.ac.uk> wrote:
>
>> I don't see the issue that you all seem to be experiencing but I can offer
>> some advice:
>> CSS, Javascript, images etc should be stored in the webapp directory NOT
>> mixed in with the rest of the classes and HTML. Your CSS can then get at
>> them easily if you are using any background images etc. Martijn mentioned
>> this and its a valid point, you can then unmount the directories and let the
>> web server serve them statically rather than Tomcat serve them which takes
>> up threads.
>>
>> You can use an IHeaderContributor to add any CSS or Javascript references
>> into the HTML header:
>>
>> public class BasePage extends WebPage implements IHeaderContributor {
>>
>> public void renderHead(IHeaderResponse response) {
>> response.renderCSSReference("css/jquery.cluetip.css");response.renderJavascriptReference(
>> "javascript/jquery.dimensions.js");
>> response.renderJavascriptReference("javascript/jquery.hoverIntent.js");
>> response.renderJavascriptReference("javascript/jquery.cluetip.js");
>> }
>>
>> If you need to add any images in your page, use a ContextImage which is
>> relative to the context always.
>>
>> I tend to use a BasePage which setups the header and have my other pages
>> extend BasePage you might find it useful as well.
>>
>>
>> cheers,
>> Steve
>>
>>
>>
>>
>>
>>
>> On 27 May 2009, at 06:40, Luther Baker wrote:
>>
>> On Tue, May 26, 2009 at 11:43 PM, Vasu Srinivasan <va...@gmail.com>
>> wrote:
>>
>> @Luther:
>>
>>
>> Yes - I'm using the ImageButton it to submit a form.
>>
>>
>> Thanks for the suggestion to use the modifier. I will try that.
>>
>>
>>
>> Great. I think it should work for you.
>>
>>
>>
>> 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.
>>
>>
>>
>> If I had to guess ... it is probably just a matter of time. There are
>> probably a lot of design and "Wicket Way" considerations the team iterates
>> through and prioritizes. I think cases like yours bring some of these
>> usage
>> points into clearer focus after-which, maybe they'll get some traction.
>>
>> My guess is that these folks are pretty busy and that there are probably
>> 10s
>> of 100s of similar requests in the queue - so just need some time ... or
>> bodies :)
>>
>>
>> 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.
>>
>>
>>
>> It sounds reasonable to me - but I'm not knee deep in the code either/yet.
>>
>> -Luther
>>
>>
>>
>
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
Hi Steve,
Continue your example and mount a url to an existing page that extends
BasePage:
mountBookmarkablePage("/im/going/home", About.class);
and tell me what happens to your js and css references when you visit that
url.
Hope that helps,
-Luther
On Wed, May 27, 2009 at 7:20 AM, Steve Swinsburg <
s.swinsburg@lancaster.ac.uk> wrote:
> I don't see the issue that you all seem to be experiencing but I can offer
> some advice:
> CSS, Javascript, images etc should be stored in the webapp directory NOT
> mixed in with the rest of the classes and HTML. Your CSS can then get at
> them easily if you are using any background images etc. Martijn mentioned
> this and its a valid point, you can then unmount the directories and let the
> web server serve them statically rather than Tomcat serve them which takes
> up threads.
>
> You can use an IHeaderContributor to add any CSS or Javascript references
> into the HTML header:
>
> public class BasePage extends WebPage implements IHeaderContributor {
>
> public void renderHead(IHeaderResponse response) {
> response.renderCSSReference("css/jquery.cluetip.css");
> response.renderJavascriptReference("javascript/jquery.dimensions.js");
> response.renderJavascriptReference("javascript/jquery.hoverIntent.js");
> response.renderJavascriptReference("javascript/jquery.cluetip.js");
> }
>
> If you need to add any images in your page, use a ContextImage which is
> relative to the context always.
>
> I tend to use a BasePage which setups the header and have my other pages
> extend BasePage you might find it useful as well.
>
>
> cheers,
> Steve
>
>
>
>
>
>
> On 27 May 2009, at 06:40, Luther Baker wrote:
>
> On Tue, May 26, 2009 at 11:43 PM, Vasu Srinivasan <va...@gmail.com>
> wrote:
>
> @Luther:
>
>
> Yes - I'm using the ImageButton it to submit a form.
>
>
> Thanks for the suggestion to use the modifier. I will try that.
>
>
>
> Great. I think it should work for you.
>
>
>
> 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.
>
>
>
> If I had to guess ... it is probably just a matter of time. There are
> probably a lot of design and "Wicket Way" considerations the team iterates
> through and prioritizes. I think cases like yours bring some of these usage
> points into clearer focus after-which, maybe they'll get some traction.
>
> My guess is that these folks are pretty busy and that there are probably
> 10s
> of 100s of similar requests in the queue - so just need some time ... or
> bodies :)
>
>
> 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.
>
>
>
> It sounds reasonable to me - but I'm not knee deep in the code either/yet.
>
> -Luther
>
>
>
Re: Storing css and image files
Posted by Steve Swinsburg <s....@lancaster.ac.uk>.
I don't see the issue that you all seem to be experiencing but I can
offer some advice:
CSS, Javascript, images etc should be stored in the webapp directory
NOT mixed in with the rest of the classes and HTML. Your CSS can then
get at them easily if you are using any background images etc. Martijn
mentioned this and its a valid point, you can then unmount the
directories and let the web server serve them statically rather than
Tomcat serve them which takes up threads.
You can use an IHeaderContributor to add any CSS or Javascript
references into the HTML header:
public class BasePage extends WebPage implements IHeaderContributor {
public void renderHead(IHeaderResponse response) {
response.renderCSSReference("css/jquery.cluetip.css");
response.renderJavascriptReference("javascript/jquery.dimensions.js");
response.renderJavascriptReference("javascript/jquery.hoverIntent.js");
response.renderJavascriptReference("javascript/jquery.cluetip.js");
}
If you need to add any images in your page, use a ContextImage which
is relative to the context always.
I tend to use a BasePage which setups the header and have my other
pages extend BasePage you might find it useful as well.
cheers,
Steve
On 27 May 2009, at 06:40, Luther Baker wrote:
> On Tue, May 26, 2009 at 11:43 PM, Vasu Srinivasan
> <va...@gmail.com> wrote:
>
>> @Luther:
>>
>> Yes - I'm using the ImageButton it to submit a form.
>>
>> Thanks for the suggestion to use the modifier. I will try that.
>>
>
> Great. I think it should work for you.
>
>
>>
>> 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.
>
>
> If I had to guess ... it is probably just a matter of time. There are
> probably a lot of design and "Wicket Way" considerations the team
> iterates
> through and prioritizes. I think cases like yours bring some of
> these usage
> points into clearer focus after-which, maybe they'll get some
> traction.
>
> My guess is that these folks are pretty busy and that there are
> probably 10s
> of 100s of similar requests in the queue - so just need some
> time ... or
> bodies :)
>
>
>> 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.
>
>
> It sounds reasonable to me - but I'm not knee deep in the code
> either/yet.
>
> -Luther
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
On Tue, May 26, 2009 at 11:43 PM, Vasu Srinivasan <va...@gmail.com> wrote:
> @Luther:
>
> Yes - I'm using the ImageButton it to submit a form.
>
> Thanks for the suggestion to use the modifier. I will try that.
>
Great. I think it should work for you.
>
> 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.
If I had to guess ... it is probably just a matter of time. There are
probably a lot of design and "Wicket Way" considerations the team iterates
through and prioritizes. I think cases like yours bring some of these usage
points into clearer focus after-which, maybe they'll get some traction.
My guess is that these folks are pretty busy and that there are probably 10s
of 100s of similar requests in the queue - so just need some time ... or
bodies :)
> 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.
It sounds reasonable to me - but I'm not knee deep in the code either/yet.
-Luther
Re: Storing css and image files
Posted by Vasu Srinivasan <va...@gmail.com>.
@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 <lu...@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 <lu...@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 <vasya10@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 <lutherbaker@gmail.com
> >> >wrote:
> >>
> >> > I like that idea!
> >> >
> >> >
> >> > On Tue, May 26, 2009 at 10:33 AM, Igor Vaynberg <
> >> igor.vaynberg@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
> >> > > <ma...@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 <
> >> lutherbaker@gmail.com>
> >> > > wrote:
> >> > > >> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
> >> > > >> martijn.dashorst@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-unsubscribe@wicket.apache.org
> >> > > > For additional commands, e-mail: users-help@wicket.apache.org
> >> > > >
> >> > > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > > For additional commands, e-mail: users-help@wicket.apache.org
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Vasu Srinivasan
> >>
> >
> >
>
--
Regards,
Vasu Srinivasan
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
@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 <lu...@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 <va...@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 <lutherbaker@gmail.com
>> >wrote:
>>
>> > I like that idea!
>> >
>> >
>> > On Tue, May 26, 2009 at 10:33 AM, Igor Vaynberg <
>> igor.vaynberg@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
>> > > <ma...@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 <
>> lutherbaker@gmail.com>
>> > > wrote:
>> > > >> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
>> > > >> martijn.dashorst@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-unsubscribe@wicket.apache.org
>> > > > For additional commands, e-mail: users-help@wicket.apache.org
>> > > >
>> > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > > For additional commands, e-mail: users-help@wicket.apache.org
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Regards,
>> Vasu Srinivasan
>>
>
>
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
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 <va...@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 <lutherbaker@gmail.com
> >wrote:
>
> > I like that idea!
> >
> >
> > On Tue, May 26, 2009 at 10:33 AM, Igor Vaynberg <igor.vaynberg@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
> > > <ma...@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 <lutherbaker@gmail.com
> >
> > > wrote:
> > > >> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
> > > >> martijn.dashorst@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-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
>
>
> --
> Regards,
> Vasu Srinivasan
>
Re: Storing css and image files
Posted by Vasu Srinivasan <va...@gmail.com>.
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 <lu...@gmail.com>wrote:
> I like that idea!
>
>
> On Tue, May 26, 2009 at 10:33 AM, Igor Vaynberg <igor.vaynberg@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
> > <ma...@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 <lu...@gmail.com>
> > wrote:
> > >> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
> > >> martijn.dashorst@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-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
--
Regards,
Vasu Srinivasan
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
I like that idea!
On Tue, May 26, 2009 at 10:33 AM, Igor Vaynberg <ig...@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
> <ma...@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 <lu...@gmail.com>
> wrote:
> >> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
> >> martijn.dashorst@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Storing css and image files
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<ma...@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 <lu...@gmail.com> wrote:
>> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
>> martijn.dashorst@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Storing css and image files
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <lu...@gmail.com> wrote:
> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
> martijn.dashorst@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Storing css and image files
Posted by Luther Baker <lu...@gmail.com>.
**On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst <
martijn.dashorst@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
Re: Storing css and image files
Posted by Martijn Dashorst <ma...@gmail.com>.
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
On Sun, May 24, 2009 at 6:17 PM, Lucas Bonansea
<lu...@gmail.com> wrote:
> Thanks for the responses, I'll try them out
>
> On Sun, May 24, 2009 at 9:51 AM, Jeremy Thomerson <jeremy@wickettraining.com
>> wrote:
>
>> The most common "wicket way" is that they are stored in your java
>> packages, next to your class and html files. This way they can be
>> packaged and reused in other applications, etc. Then you reference
>> them with a resourcereference(ClassNextToThem.class,
>> "relative-path-from-class").
>>
>> Or you can put them in the same place and use wicket:link rather than
>> a resource reference. Up to you.
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>>
>> On Sat, May 23, 2009 at 9:10 PM, Lucas Bonansea
>> <lu...@gmail.com> wrote:
>> > Hello.
>> > I'm new to web development and to Wicket. I created an Wicket
>> > project in Eclipse following the instructions in the website, from there
>> and
>> > following the examples I have been able to create a couple of simple web
>> > pages. The problem I am having, is that I don't know where to store my
>> css
>> > file and my image files so that they would be loaded when I execute my
>> new
>> > web pages.
>> > If possible I would like to do it using relative paths so then
>> I
>> > can deploy my war elsewhere
>> >
>> > Thanks
>> >
>> > Lucas B
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
--
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Storing css and image files
Posted by Lucas Bonansea <lu...@gmail.com>.
Thanks for the responses, I'll try them out
On Sun, May 24, 2009 at 9:51 AM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
> The most common "wicket way" is that they are stored in your java
> packages, next to your class and html files. This way they can be
> packaged and reused in other applications, etc. Then you reference
> them with a resourcereference(ClassNextToThem.class,
> "relative-path-from-class").
>
> Or you can put them in the same place and use wicket:link rather than
> a resource reference. Up to you.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
>
> On Sat, May 23, 2009 at 9:10 PM, Lucas Bonansea
> <lu...@gmail.com> wrote:
> > Hello.
> > I'm new to web development and to Wicket. I created an Wicket
> > project in Eclipse following the instructions in the website, from there
> and
> > following the examples I have been able to create a couple of simple web
> > pages. The problem I am having, is that I don't know where to store my
> css
> > file and my image files so that they would be loaded when I execute my
> new
> > web pages.
> > If possible I would like to do it using relative paths so then
> I
> > can deploy my war elsewhere
> >
> > Thanks
> >
> > Lucas B
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Storing css and image files
Posted by Jeremy Thomerson <je...@wickettraining.com>.
The most common "wicket way" is that they are stored in your java
packages, next to your class and html files. This way they can be
packaged and reused in other applications, etc. Then you reference
them with a resourcereference(ClassNextToThem.class,
"relative-path-from-class").
Or you can put them in the same place and use wicket:link rather than
a resource reference. Up to you.
--
Jeremy Thomerson
http://www.wickettraining.com
On Sat, May 23, 2009 at 9:10 PM, Lucas Bonansea
<lu...@gmail.com> wrote:
> Hello.
> I'm new to web development and to Wicket. I created an Wicket
> project in Eclipse following the instructions in the website, from there and
> following the examples I have been able to create a couple of simple web
> pages. The problem I am having, is that I don't know where to store my css
> file and my image files so that they would be loaded when I execute my new
> web pages.
> If possible I would like to do it using relative paths so then I
> can deploy my war elsewhere
>
> Thanks
>
> Lucas B
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org