Fortunately my webapp isn't that complex :)
I only modify the bundled EXE when a new version comes out and whenever
I do that I need to update the webapp to point to a new filename anyway
(I'd have to do the same if I had plain HTML) so it really isn't much of
a stretch having to redeploy the webapp everytime I make an update to
the EXE file.
My actual application (server-end) is a different beast and I do pretty
much what you mention :)
Gili
Eelco Hillenius wrote:
Ok. It'll make Wicket's design better when we have that.
Ofcourse, you are free to choose whatever packaging strategy you choose.
It means however, that if you decide to update the download, or maybe
want to have additionial downloads available, you have to redeploy your
web application. From an architecture point of view, that doesn't seem
wise. You wouldn't usually pack database contents in a jar file either
right? I know you're not asking, but *I* would probably use some
(absolute) directory on the server (like one you can access directly
with FTP/SCP), and create download links either from reading that
directory (means less maintenance, but also less control, and in that
case you might also consider just exposing as an FTP dir), or to have
e.g. a database mapping to those links (more maintenance, but gives you
full control of which files to expose, and you can attach all kinds of
meta data).
Just my 2c.
Eelco
Gili wrote:
I'm fine for making this a RFE for 1.1 but you better file it
because I'm not familiar with the design you have in mind.
As for why I am packaging EXEs in my JAR... the way I see it, if I
wanted to use the old-school "flat directory" structure, I'd be using
JSP.
When using Wicket, I plan on deploying all my pages in an
object-oriented manner such that they are self-contained (all
referenced resources show up in sub-packages). From my perspective, it
is much cleaner that way. I'm actually trying to complement Wicket
here :)
Gili
Eelco Hillenius wrote:
Like I said, I think it can't be done easily. It would mean changing
the resoure locator mechanism in order to find out excactly for what
style/ locale combination the first match was found. That change
would be for the better, but I don't want to do that for 1.0, as I
think it is quite unlikely that many users will serve resources other
than images from their Java packages. Are you actually packaging your
.exe in a jar? A more likely case is that users serve those resources
from their webapplication, or even outside of their webapplication
(like a corparate store).
So... let's make this a 1.1 RFE (or submit a *working*, fully tested
patch).
Eelco
Gili wrote:
Unfortunately, the workaround you mention does not work. You
still end up with the locale as part of the client-side filename.
The only way I got it to work is by subclassing Link and overriding
this method:
protected String getURL()
{
resourceReference.bind(getApplication());
return getPage().urlFor(resourceReference.getPath());
}
and this basically drops the locale and style. The bad part
about all of this is that it is far from obvious to end-users that
they need to do all of this. I only discovered it by trial and error
and looking at the source-code, something end-users should not have
to do.
Coming back to the original question, why does have to be
implemented this way in order to support localized resources? Why
can't it simply use the search order I mentioned (in a separate email)?
That is, look for localized filenames first, if the server-side
files exist return them. If they do not exist, look for a
non-localized filename, if it exists return it. Finally, if all
other conditions fail, return a broken link.
Gili
Eelco Hillenius wrote:
Nope, not my bad, it must be done like this in order to support
localized resources. However, for non-localized resources, there is
an easy workaround:
StaticResourceReference resource = new
StaticResourceReference(DogFoodPage.class, "doggybag.exe")
{
protected wicket.Resource newResource()
{
return StaticResource.get(getScope().getPackage(),
getName());
};
};
add(new ResourceLink("downloadLink", resource));
And if your really want to do it localized, you have to pre-bind
the references for the available locales and provide a custom
ResourceLink where you override getURL.
Eelco
Eelco Hillenius wrote:
Ok, that's probably my bad. I didn't expect it to be a problem for
anyone, but I'll see if it is possible to fix it.
Eelco
Gili wrote:
I mean that if I have the file doggybag.exe on the server
which I link to using ResourceLink, when the client clicks on the
link in his browser, he gets a message about downloading
doggybag_en_us.exe which is incorrect.
I am sending an install program of my application to
end-users and I don't want the filename mangled in any way.
Gili
Juergen Donnerstag wrote:
Sorry, but I don't understand what you mean.
Juergen
On 5/30/05, Gili <[EMAIL PROTECTED]> wrote:
The problem isn't finding the file on the server end. The
problem is
that even if it files a locale-less filename on the server-end,
it still
sends appends to the locale on the client-end (HTML code).
Is this a bug then?
Gili
Juergen Donnerstag wrote:
Without having taken a look into the source: ResourceLink
tries to
load a resource with locale + style, locale, style and without
anything, it should work as long as the resource file does not
have
the locale or style attached. I know there is a log4j setting
for the
class to enable logging on which filenames are checked for
existence.
Again, I didn't look into the source, I might be wrong.
Juergen
On 5/30/05, Gili <[EMAIL PROTECTED]> wrote:
Hi,
Is it possible to create a ResourceLink that never
appends anything to
the filename like locale? I tried extending ResourceLink but
it is
impossible to either override getLocale(), getStyle() to
always return
null because they are final methods nor is it possible to
override
getURL() because "resourceReference" is a private field.
If I *am* supposed to be subclassing ResourceLink,
please consider
making resourceReference protected. Otherwise, I am open to your
suggestions.
Thank you,
Gili
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps
using Yahoo!
Search APIs Find out how you can build Yahoo! directly into
your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps
using Yahoo!
Search APIs Find out how you can build Yahoo! directly into
your own
Applications - visit
http://developer.yahoo.net/?fr=fad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using
Yahoo!
Search APIs Find out how you can build Yahoo! directly into
your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using
Yahoo!
Search APIs Find out how you can build Yahoo! directly into your
own
Applications - visit
http://developer.yahoo.net/?fr=fad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using
Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using
Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
