You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Mind Bridge <mi...@yahoo.com> on 2005/07/06 01:23:19 UTC
Registering a squeezer adaptor
Hi,
What is the best way to register a custom data squeezer adaptor in 4.0? Is
that functionality complete?
-mb
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Registering a squeezer adaptor
Posted by Mind Bridge <mi...@yahoo.com>.
Hi,
> I suspect you could change the code to generate THREE representations
> (binary, binary gzip and textual), and keep the shortest encoding.
This is exactly how I envisaged it as well. I was initially thinking of
adding a squeezer for PropertyChange objects to enable the textual
representation, but then that functionality is too specific to the framework
so it simply could be built-in.
> However, another thing I've wanted to look into was to add the ability
> to pass the binary object stream through an encrypter/decrypter, for
> security reasons. That would NOT mesh well with a textual
> representation.
Do you mean in the general case, or for a particular property for which it
is indicated that needs to be secure?
In the general case, it seems to me that some sort of a digital signature
would be quite helpful, as it would prevent people from modifying the URLs
generated by Tapestry and would close a lot of potential security holes if
there are problems in the application (something to be expected in larger
codebases).
In the user case, I guess we could simply define a standard serializable
(externalizable) wrapper that performs the encryption when it is serialized.
That would be a bit more work than simply indicating that the property needs
to be secure (using annotations or in the spec), but then again that is not
a very frequent requirement and the implementation could easily go into
contrib...
Best regards,
-mb
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Thursday, July 07, 2005 9:47 PM
Subject: Re: Registering a squeezer adaptor
On 7/6/05, Mind Bridge <mi...@yahoo.com> wrote:
> Hi Howard,
>
> Any problems for me to implement adding sqeezer adaptors in the way adding
> ASOs are implemented (using a configration point)?
Nope, that's my "vision".
>
> One other issue -- client persistence always uses the serialization
approach
> at the moment. Is there a problem with using the registered data sqeezers?
> That would make URLs significantly shorter (and readable) in some cases. I
> understand that some quoting may be necessary, but I am wondering if there
> is a problem beyond that.
What's getting encoded is a series of PropertyChange objects, each
identifying the component id path (optional), the property name, and
the property value. Each of these is streamed into an
ObjectOutputStream, the result is optionally gzipped, then mime
encoded. So using the squeezer isn't the right approach.
I suppose you could have the query string be:
state:MyPage=Tfoo,bar,99,zip,,SFred
That would be:
"T" prefix is "textual representation" (i.e., not binary)
property foo of component bar is 99
property zip (of the page) is the string "Fred"
In the existing code, the initial character identifies how the
remainder is "encoded". Currently, its used to determine if a
GzipInputStream is needed.
I suspect you could change the code to generate THREE representations
(binary, binary gzip and textual), and keep the shortest encoding.
However, another thing I've wanted to look into was to add the ability
to pass the binary object stream through an encrypter/decrypter, for
security reasons. That would NOT mesh well with a textual
representation.
A final note; the serialization-based SqueezeAdaptor should share code
with the binary/binary gzipped approach and support optional
encryption as well. It also doesn't need to use its mutant Base64
encoding; standard Base64 should work fine (since element attributes
are URL encoded anyway by the Markup Writer).
>
> -mb
>
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Thursday, July 07, 2005 2:46 AM
> Subject: Re: Registering a squeezer adaptor
>
>
> Not really; I've been meaning to loop back, define a configuration
> point for setting adaptors, and add logic to the service impl to
> initialize from that configuration point.
>
> On 7/5/05, Mind Bridge <mi...@yahoo.com> wrote:
> > Hi,
> >
> > What is the best way to register a custom data squeezer adaptor in 4.0?
Is
> > that functionality complete?
> >
> > -mb
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Registering a squeezer adaptor
Posted by Howard Lewis Ship <hl...@gmail.com>.
On 7/6/05, Mind Bridge <mi...@yahoo.com> wrote:
> Hi Howard,
>
> Any problems for me to implement adding sqeezer adaptors in the way adding
> ASOs are implemented (using a configration point)?
Nope, that's my "vision".
>
> One other issue -- client persistence always uses the serialization approach
> at the moment. Is there a problem with using the registered data sqeezers?
> That would make URLs significantly shorter (and readable) in some cases. I
> understand that some quoting may be necessary, but I am wondering if there
> is a problem beyond that.
What's getting encoded is a series of PropertyChange objects, each
identifying the component id path (optional), the property name, and
the property value. Each of these is streamed into an
ObjectOutputStream, the result is optionally gzipped, then mime
encoded. So using the squeezer isn't the right approach.
I suppose you could have the query string be:
state:MyPage=Tfoo,bar,99,zip,,SFred
That would be:
"T" prefix is "textual representation" (i.e., not binary)
property foo of component bar is 99
property zip (of the page) is the string "Fred"
In the existing code, the initial character identifies how the
remainder is "encoded". Currently, its used to determine if a
GzipInputStream is needed.
I suspect you could change the code to generate THREE representations
(binary, binary gzip and textual), and keep the shortest encoding.
However, another thing I've wanted to look into was to add the ability
to pass the binary object stream through an encrypter/decrypter, for
security reasons. That would NOT mesh well with a textual
representation.
A final note; the serialization-based SqueezeAdaptor should share code
with the binary/binary gzipped approach and support optional
encryption as well. It also doesn't need to use its mutant Base64
encoding; standard Base64 should work fine (since element attributes
are URL encoded anyway by the Markup Writer).
>
> -mb
>
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Thursday, July 07, 2005 2:46 AM
> Subject: Re: Registering a squeezer adaptor
>
>
> Not really; I've been meaning to loop back, define a configuration
> point for setting adaptors, and add logic to the service impl to
> initialize from that configuration point.
>
> On 7/5/05, Mind Bridge <mi...@yahoo.com> wrote:
> > Hi,
> >
> > What is the best way to register a custom data squeezer adaptor in 4.0? Is
> > that functionality complete?
> >
> > -mb
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Registering a squeezer adaptor
Posted by Mind Bridge <mi...@yahoo.com>.
Hi Howard,
Any problems for me to implement adding sqeezer adaptors in the way adding
ASOs are implemented (using a configration point)?
One other issue -- client persistence always uses the serialization approach
at the moment. Is there a problem with using the registered data sqeezers?
That would make URLs significantly shorter (and readable) in some cases. I
understand that some quoting may be necessary, but I am wondering if there
is a problem beyond that.
-mb
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Thursday, July 07, 2005 2:46 AM
Subject: Re: Registering a squeezer adaptor
Not really; I've been meaning to loop back, define a configuration
point for setting adaptors, and add logic to the service impl to
initialize from that configuration point.
On 7/5/05, Mind Bridge <mi...@yahoo.com> wrote:
> Hi,
>
> What is the best way to register a custom data squeezer adaptor in 4.0? Is
> that functionality complete?
>
> -mb
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Registering a squeezer adaptor
Posted by Howard Lewis Ship <hl...@gmail.com>.
Not really; I've been meaning to loop back, define a configuration
point for setting adaptors, and add logic to the service impl to
initialize from that configuration point.
On 7/5/05, Mind Bridge <mi...@yahoo.com> wrote:
> Hi,
>
> What is the best way to register a custom data squeezer adaptor in 4.0? Is
> that functionality complete?
>
> -mb
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org