although I'm not yet using Cayenne, I do use a custom data squeezer for
an object we're passing around in our Registrar app. It really was a
great way to go. The object encapulates what we need and Tapestry does
the magic automatically. A middle-sized object gets sqeezed into this on
the URL:
sp=y1/1/99/1/1/10/null/null/null/1/1/0/0/3.0/10/null
While that looks long, can you imagine how long the standard
serialization string would be? Many hundreds of characters.
The hardest part of the design was finding an unused letter for the
registry ("y" here).
One thing Richard added was to put the squeeze() code into the object
itself so only one object had to be modified as we developed. He made a
constructor that takes the sqeezed object and converts it back into the
unsqueezed object. So our squeezer ended up with sqeeze() and
unsqueeze() methods that look like this:
public String squeeze(DataSqueezer squeezer, Object data) throws
IOException {
SectionActionItem item = (SectionActionItem) data;
return item.squeeze();
}
public Object unsqueeze(DataSqueezer squeezer, String string) throws
IOException {
return new SectionActionItem(string);
}
Jamie
Eric Schneider wrote:
> Erik,
>
>> I'm going to start using Cayenne "in anger" shortly
>
>
> Welcome to the community...i guess?? Hopefully we can make your
> experience less awful.
>
> Cheers,
> e.
>
> On Mar 31, 2005, at 11:23 AM, Erik Hatcher wrote:
>
>> On Mar 31, 2005, at 9:19 AM, Robert Zeigler wrote:
>>
>>> Erik Hatcher wrote:
>>>
>>>> Regarding using a rich (i.e. not a String or simple type) object as a
>>>> parameter in a DirectLink - this is not really recommended in the
>>>> general sense. The URL is going to be hideous and perhaps even too
>>>> long
>>>> for some browsers to handle.
>>>>
>>>> A trick within Tapestry, though, would be to use a custom DataSqueezer
>>>> that serialized only the primary key and a unique prefix, and then
>>>> "deserialized" by fetching again using the facility Andrus describes
>>>> below. I have not tried this route - have others?
>>>>
>>>> Erik
>>>>
>>>
>>> I haven't, but it's a good idea that solves the problem exactly once.
>>> I just did a quick once-over of the DataSqueezer implementation...
>>> there
>>> are some questions still lurking in my mind about this approach.
>>> 1) In order to "deserialize" the object, you're going to need access to
>>> the correct DataContext from within a custom adaptor. If you store the
>>> datacontext in the visit, then this could be solved by using a
>>> ThreadLocal Engine approach, I suppose. Or, you could use the utilities
>>> provided by andrus for binding a dc. to a thread, and getting the
>>> thread
>>> local dc. Correct me if I'm wrong, Erik, but, at least in tapestry
>>> 3.0,
>>> wouldn't you need to sublcass BaseEngine anyway to override
>>> createDataSqueeezer() to return an instance that contains the custom
>>> squeeze adaptor?
>>
>>
>> I had to look up the details myself. I'm trying to migrate entirely
>> into Tapestry 3.1, so I had to go back in time :) In 3.1, adaptors
>> are registered with HiveMind. In 3.0, you'll do something like this
>> in a BaseEngine subclass:
>>
>> public DataSqueezer createDataSqueezer() {
>> DataSqueezer squeezer = new
>> DataSqueezer(getResourceResolver(), new ISqueezeAdaptor[] { new
>> CustomAdaptor()});
>> return squeezer;
>> }
>>
>> Yeah, getting the right context in the squeezer is the trick and it
>> seems like ThreadLocal is a great trick.
>>
>> I'm going to start using Cayenne "in anger" shortly, but at this
>> point I know next to nothing about it so I don't have any specific
>> Tapestry/Cayenne advice at this point.
>>
>> Erik
>>
>>
>>>
>>> Robert
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Thu Mar 31 2005 - 16:22:47 EST