You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Barry Books <tr...@gmail.com> on 2011/09/29 16:22:10 UTC

Proposal for an Application Defaults solution

I've been think about Howard's email a couple of days ago and it
occurred to me that while Tapestry provides a very good set of tools
for solving common problems encountered doing web development it does
not actually solve them. This is not a complaint and in fact I think
it's the right approach for a framework, but I think in order to build
a community around Tapestry these common problems need a common
solution. The great thing about Tapestry and IOC is you can build a
common solution and then either replace or extend it.

During this same time I noticed a couple of email about how to
implement defaults. Tapestry provides a way to do this buy it's
completely static. That's a good start but it does not really solve
the application development problem.

Problem Definition:
There needs to be a way to have defaults for various values used by an
application. Defaults should be provided by modules. It should be
possible to override these defaults via the Tapestry IOC applications
default mechanism. And finally it should be possible to override this
defaults and runtime. The runtime mechanism may be provided by the
application so defaults could for example be stored in a database.
Lastly the override mechanism should allow overriding the defaults
based on the context.

While this sounds like a pretty tall order thanks to the tools
provided by Tapestry it's actually pretty easy.

The Solution:
There are a few parts to the solution.

1. Implement a binding prefix called default which can retrieve the
default for a key
2. Provide a way to contribute module defaults
3. Provide a service that can retrieve defaults for a binding key

Creating a binding prefix is easy:

https://github.com/trsvax/tapestry-trsvax/blob/master/src/main/java/com/trsvax/tapestry/misc/services/DefaultBinding.java

Contributing binding defaults is even easier:

public final static String id = "MiscModule";

    @Contribute(Defaults.class)
    public static void contributeDefautls(MappedConfiguration<String,
StaticDefaults> configuration) {
    	configuration.add(id,new MyDefaults());
    }

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: Proposal for an Application Defaults solution

Posted by Barry Books <tr...@gmail.com>.
I can see the overlap but I think the Metadata service is only for
pages/components and I was looking for a general purpose application
default solution. For example you could store the email address for
the site admin in here. I don't think the MetaData service would be
appropriate for that.

Perhaps the other bit I was not clear about is the standardized way
the keys are stored. For example the defaults for a module are stored
in this format.

public class MyDefaults extends AbstractStaticDefaults implements
StaticDefaults  {
	 public final static String defaultKey = "default:" + MiscModule.id +
":defaultKey:abc";
}

This allows the default service to look them up by module id, provides
a namespace and the default value is obvious.

I can see the two working together. The real problem I trying to solve
is a common solution that is easily used by module builders as well as
application builders that allows defaults to be stored in an
application specific way (most likely a database). Currently the
pieces are there what's lacking I think is a convention for doing it.
Without the convention everyone solves the problem in a different way
and the modules/applications cannot interoperate easily.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: Proposal for an Application Defaults solution

Posted by Howard Lewis Ship <hl...@gmail.com>.
Seems like this overlaps strongly with meta data for pages; perhaps
expanding that, and adding a meta: binding prefix, would address this
better.

http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/MetaDataLocator.html

On Thu, Sep 29, 2011 at 7:32 AM, Barry Books <tr...@gmail.com> wrote:
> Sorry about the 2 part email.
>
> The service to fetch the defaults is also pretty simple
>
> https://github.com/trsvax/tapestry-trsvax/blob/master/src/test/java/com/trsvax/tapestry/misc/services/DefaultsImpl.java
>
> So with these 3 parts you can do things like:
>
> In a comonent
>        @Parameter(MyDefaults.defaultKey)
>        private String value;
>
> In a tml file
>       ${default:MiscModule:defaultKey:abc}
>
> In your appModule
>    public void
> contributeApplicationDefaults(MappedConfiguration<String, String>
> configuration)
>    {
>      configuration.add(MyDefaults.defaultKey, "WackyCollaborator");
>    }
>
> Since the Default service has access to the Location and the Component
> you can override defaults based on the page or the component complete
> id. Lastly since you can provide your own Default service you can
> drive the final default value from your database (or whatever).
>
> If all the modules use something like this it would allow applications
> to have fine grain control over the defaults for services and
> components. For example I could default the grid pager rows to 50 on
> one page and 10 one another. If I needed to I could control the zone
> refresh color and style by user.
>
> Comments?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: Proposal for an Application Defaults solution

Posted by Barry Books <tr...@gmail.com>.
Sorry about the 2 part email.

The service to fetch the defaults is also pretty simple

https://github.com/trsvax/tapestry-trsvax/blob/master/src/test/java/com/trsvax/tapestry/misc/services/DefaultsImpl.java

So with these 3 parts you can do things like:

In a comonent
	@Parameter(MyDefaults.defaultKey)
	private String value;

In a tml file
       ${default:MiscModule:defaultKey:abc}

In your appModule
    public void
contributeApplicationDefaults(MappedConfiguration<String, String>
configuration)
    {
      configuration.add(MyDefaults.defaultKey, "WackyCollaborator");
    }

Since the Default service has access to the Location and the Component
you can override defaults based on the page or the component complete
id. Lastly since you can provide your own Default service you can
drive the final default value from your database (or whatever).

If all the modules use something like this it would allow applications
to have fine grain control over the defaults for services and
components. For example I could default the grid pager rows to 50 on
one page and 10 one another. If I needed to I could control the zone
refresh color and style by user.

Comments?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org