Datastore localisation - Sanity check

[Ned Collyer <ne...@gmail.com>]

Hi,

I want to use my own localisation service.  This allows me to handle the
properties differently via a GUI from within the app, or from another
location, and gives customers / implementors a bit more power.

Thing I'm working on will have components that can be translated and
customised for many different locales.  These should can be managed the
clients themselves during runtime.  Ideally, there should be an "export"
function from the GUI to extract an appropriately named resource file to
contribute back into the central code base. (ie, "value adding" to the
software as its used more).  Also, if there is nothing in the database, it
would roll back to the properties files.

I love the properties files approach, and the way wicket has its property
overrides determined (eg in ComponentStringResourceLoader).

What I am planning on doing is extending the ResourceStreamLocator as I can
use the "super" calls in a more elegant fashion than extending the
PropertiesFactory and having to reimplement much of its functionality. 
PropertiesFactory does not appear very 

So I'll end up with something like

public class MyResourceStreamLocator extends ResourceStreamLocator
    public IResourceStream locate(Class clazz, String path) {
        IResourceStream stream = locateFromDatastore(clazz, path);
        if (stream != null) {
            return stream;
        }

        return super.locate(clazz, path);
    }
}

This seems like an elegant approach to datastore localisation which retains
all of the existing functionality (property resolution, cascade of
properties files, cache) and gives rollback to standard wicket properties
files.

I can easily clear the caches.

The only downfall I can see is that because it is "per file" based, I need
to ensure that if I override any properties in a given file, the entire file
is in the datastore.

I believe I could put CSS and JS into the db too.. although this is not
planned.

Any thoughts?
-- 
View this message in context: http://www.nabble.com/Datastore-localisation---Sanity-check-tp15451880p15451880.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Datastore localisation - Sanity check

[Igor Vaynberg <ig...@gmail.com>]

looks ok.

-igor


On Feb 13, 2008 1:22 AM, Ned Collyer <ne...@gmail.com> wrote:
>
> Hi,
>
> I want to use my own localisation service.  This allows me to handle the
> properties differently via a GUI from within the app, or from another
> location, and gives customers / implementors a bit more power.
>
> Thing I'm working on will have components that can be translated and
> customised for many different locales.  These should can be managed the
> clients themselves during runtime.  Ideally, there should be an "export"
> function from the GUI to extract an appropriately named resource file to
> contribute back into the central code base. (ie, "value adding" to the
> software as its used more).  Also, if there is nothing in the database, it
> would roll back to the properties files.
>
> I love the properties files approach, and the way wicket has its property
> overrides determined (eg in ComponentStringResourceLoader).
>
> What I am planning on doing is extending the ResourceStreamLocator as I can
> use the "super" calls in a more elegant fashion than extending the
> PropertiesFactory and having to reimplement much of its functionality.
> PropertiesFactory does not appear very
>
> So I'll end up with something like
>
> public class MyResourceStreamLocator extends ResourceStreamLocator
>     public IResourceStream locate(Class clazz, String path) {
>         IResourceStream stream = locateFromDatastore(clazz, path);
>         if (stream != null) {
>             return stream;
>         }
>
>         return super.locate(clazz, path);
>     }
> }
>
> This seems like an elegant approach to datastore localisation which retains
> all of the existing functionality (property resolution, cascade of
> properties files, cache) and gives rollback to standard wicket properties
> files.
>
> I can easily clear the caches.
>
> The only downfall I can see is that because it is "per file" based, I need
> to ensure that if I override any properties in a given file, the entire file
> is in the datastore.
>
> I believe I could put CSS and JS into the db too.. although this is not
> planned.
>
> Any thoughts?
> --
> View this message in context: http://www.nabble.com/Datastore-localisation---Sanity-check-tp15451880p15451880.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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