wow, such a long thread for something so trivial just create a servlet that streams files from some place on the harddrive, then have your designers upload images there. done and done.
-igor On 9/28/07, V. Jenks <[EMAIL PROTECTED]> wrote: > > > No, this is not the case. I specifically need these images to be > *outside* > of the packaged .ear application because I need our designers to have > access > to them. Wicket access these resources and actually sends the contents of > the html template. > > I am also stuck at Wicket 1.2.4 because upgrading has thrown a bunch of > errors and I just do not have time to figure out the differences in the > later releases, this app has to be done today and I'm on the very last > feature, which is getting remote images to resolve through an HTML email, > which do not reside in the .ear (and therefore do not have their own > hard-coded, publicly-available URL). > > I can send the email, I'm just at the point where I need how to figure out > how to get the non-packaged image resources to show up to customers who > receive it. > > > Craig Tataryn wrote: > > > > If I'm understanding this correctly you simply want a set of images > > available on the same server that your wicket app is on. Just make an > > "images" folder at the same level as WEB-INF (that is, a sibling of). > > > > If you are using wicket 1.2.x, you would have mounted your wicket app > > to some path under your context: for instance /app. A link to a > > wicket page mounted to /home would look like this: > > > > http://yourserver.com/yourcontext/app/home > > > > A link to an image would look like this: > > http://yourserver.com/yourcontext/images/myimage.jpg > > > > On Wicket 1.3, you use a filter instead, and the filter is smart > > enough to know what content to handle so technically you don't need > > the extra /app path you can reference your application and static > > images like so: > > > > http://yourserver.com/yourcontext/home > > > > http://yourserver.com/yourcontext/images/myimage.jpg (it's the same as > > before) > > > > Again, not sure if that's what you are asking, but hopefully it is! > > > > Craig. > > > > On 9/28/07, V. Jenks <[EMAIL PROTECTED]> wrote: > >> > >> Basically, yes. I wasn't sure if there was a Wicket solution to this > >> problem > >> or not. I wasn't sure if there was a way to make a hard-coded > reference > >> to > >> a resource outside of the webroot, for the purposes of doing what I > >> explained. > >> > >> > >> Eelco Hillenius wrote: > >> > > >> >> Interesting... This might work, however I don't understand what the > >> >> class > >> >> would be? Would it be the Application class? The images reside in > >> >> C:\AppName\images, which is obviously outside of the app. > >> > > >> > Oh, ok, I didn't understand what you meant. So you don't want to just > >> > put these images in a path than can be served by a web server? > >> > > >> > Eelco > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/Displaying-images-remotely---HTML-email-tf4535313.html#a12944856 > >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: > http://www.nabble.com/Displaying-images-remotely---HTML-email-tf4535313.html#a12945183 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
