For previewability reasons myScript.js must be in the package, and at
runtime href URL must be converted into
/resources/<scope>/myScript_<style>_<locale>.js depending on users
actuall style, variation and locale.

ok this will be generated if the myScript_style_locale.js is there.
Then you will have such an url.
 

>  why do you want the locale to tbe taken into account?
>  the file is not there so it can't serve it anyway.
>

because the user might have style or locale dependent js scripts.
the files are in the package

as i said then the url will have locale and/or style attributes
So only if the file is REALLY there the url will have locale attributes.
It will default to what ever is there in youre package.


>  You do want a package resource that has a href that has a locale which
> points to a file lets say:
>
>  foo_De.bar which even isn't there? because only foo.bar is there?

yes. Like we always handle i18n resources, correct?

yes
 

>
>  i think simplifing this will be hard.This is there because of all the
> locales that where in the name of all the files.
>

Actually I was thinking about another approach which I think has been
discussed on the list a couple of weeks ago as well.
WebRequestCycle.parseRequest () parses the URL to determine how to
react on it. I was thinking about extending it and to allow for user
extensible handling. A possible user implementation might look like

        /**
         * Subclasses may implement there own strategies to return static content.
         * The default implementation only returns css and js files matching the url
         * path and found by the class loader.
         *
         * @return 1 - returning a page; 2 - static content (no Page); else - not found
         */
        protected int doParseRequest()
        {
                final String path = Strings.beforeLast(request.getPath(), '.').substring(1);
                final String extension = '.' + Strings.afterLast(request.getPath(), '.');
                if (".css".equalsIgnoreCase(extension) || ".js".equalsIgnoreCase(extension))
                {
                    final IResourceStream stream = new
ClassLoaderResourceStreamLocator().locate(
                            getClass().getClassLoader(), path, session.getStyle(),
session.getLocale(),
                            extension);

                        if (stream != null)
                        {
                                final Resource resource = new Resource()
                                {
                                        private static final long serialVersionUID = 1L;

                                        public IResourceStream getResourceStream()
                                        {
                                                return stream;
                                        }
                                };
                                resource.onResourceRequested();

                                // Found static resource
                                return 2;
                        }
                }

                // Did not found the resource
                return 0;
        }

It is only an example. I personally wouldn't like to expose the
package structure to the user, it is only to show what would be
possible. It would go last after all our current url parsing has
finished and thus wouldn't require any changes to any existing
application but would give users more possibilities to extend url
handling. What do you think?


This seems fine to me.
(i have to see it as a whole first)
But don't use a PackageResourceReference for this to generate the url/href

This seem something like a special reference to me.

johan

Reply via email to