You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by James Carman <ja...@carmanconsulting.com> on 2006/06/06 14:08:21 UTC
Tapernate Squeezer...
For those of you who are using Tapernate (and those of you who have done
something similar in the past), I have a question for you. Currently, the
Tapernate entity squeezer uses an abbreviation for the class name (basically
an integer). However, I was thinking that this might not be a good thing
for external links. What would happen if the application is restarted and
someone has bookmarked an external link? So, I need to come up with a
reliable/repeatable way to "shrink" the entity name down to a small string.
Now, the situation gets even trickier when you consider the fact that your
application may add entity classes between releases. Therefore, I can't
just sort the entity class names and then assign them a number (their index
in a list). I *really* don't want the entire entity name in the URLs. That
would look kind of cheesy. The way I see it, there are some options...
1. Use a message digest of the entity name. The message digests would all
be the same length, so we wouldn't have to worry about the URLs "growing"
when the entity name grew. But, there *is* the chance for digest collisions
(digest of entity name A is the same as digest of entity name B).
2. Use the hashCode() of the entity name Strings. Again, we've got the
possibility for collisions.
3. Just use the "simple" entity name (the part of the name after the last
'.'). I don't think Hibernate requires that you have unique "simple" names
for your entity classes. In practice, this is typically not a problem.
But, in general, it's not a robust solution.
4. Just use the entire entity name and don't worry about all of this!
Users can override it if they wish and how they wish.
I will be creating a service point which does the translation to/from the
entity name abbreviation and users can override it if they want. Which of
these (or if you have other ideas) would be the best "default", though? The
entity squeezer will detect when there is a collision and either throw an
exception or print an error message to the logs (haven't decided yet) to let
you know that you need to come up with a better solution for entity name
abbreviation.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapernate Squeezer...
Posted by James Carman <ja...@carmanconsulting.com>.
The Tapernate entity squeezer has now been updated to include the
aforementioned changes. The documentation
(www.carmanconsulting.com/tapernate) has been updated to reflect the new
configuration options available for the squeezer. Enjoy!
James
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Tuesday, June 06, 2006 7:52 PM
To: 'Tapestry users'
Subject: RE: Tapernate Squeezer...
That's the way I went with it. I also made a configurable option (set via a
FactoryDefault symbol) that will allow you to tell it whether or not to use
the "short name" of the classes or not. The default is to use the short
name.
-----Original Message-----
From: Ted Steen [mailto:ted.steen@gmail.com]
Sent: Tuesday, June 06, 2006 7:42 PM
To: Tapestry users
Subject: Re: Tapernate Squeezer...
Hi,
I too like the idea of a configuration point for the substitutions.
I can't see a way to convert the name into something more simple,
without the risk of getting collisions and/or somewhat ugly URLs.
With a configuration point one will be able to;
* Get the abbreviation of the entity class to be as small as a single
character
* Have no collisions
* Rename an entity without problems
* "Force"/entices us to configure our own abbreviations, which is
good because otherwise there could be trouble when renaming entities.
2006/6/6, Andreas Andreou <an...@di.uoa.gr>:
> James Carman wrote:
> > Actually, I like Adreas Androu's idea. He said (from the developers
list):
> >
> > "I think I would use the entire entity name enhanced with an optional
> > properties file that would allow users to define substitutions."
> >
> > However, I'm going to go one better. Instead of using a properties
file,
> > I'll create a configuration point for the overrides. That's the
"HiveMind
> > Way."
> >
> hehe! Actually I initially meant to write:
> "I think I would use the entire entity name enhanced with substitutions"
> feeling that you'll make out the missing parts
> > When I said "use the hashCode()", I meant to use the hashCode() of the
> > entity name (a String) itself, not of the entity.
> >
> > -----Original Message-----
> > From: Andreas Bulling [mailto:andreas@phoenix.hadiko.de] On Behalf Of
> > Andreas Bulling
> > Sent: Tuesday, June 06, 2006 8:24 AM
> > To: Tapestry users
> > Subject: Re: Tapernate Squeezer...
> >
> > Hi James,
> >
> > I'd vote for the hashCode() approach, why:
> >
> > 1) It's the approach already used and widely accepted (for example
> > in Hibernate)
> >
> > 2) using Hibernate (which is what Tapernate is dedicated to) you
> > are advised to implement hashCode() and equals() anyway (according
> > to the Hibernate homepage) so it's no additional expense to use
> > it for Tapernate.
> >
> > Just my two cents...
> > Andreas
> >
> > On 06. Jun 2006 - 08:08:21, James Carman wrote:
> > | For those of you who are using Tapernate (and those of you who have
done
> > | something similar in the past), I have a question for you. Currently,
the
> > | Tapernate entity squeezer uses an abbreviation for the class name
> > (basically
> > | an integer). However, I was thinking that this might not be a good
thing
> > | for external links. What would happen if the application is restarted
and
> > | someone has bookmarked an external link? So, I need to come up with a
> > | reliable/repeatable way to "shrink" the entity name down to a small
> > string.
> > | Now, the situation gets even trickier when you consider the fact that
your
> > | application may add entity classes between releases. Therefore, I
can't
> > | just sort the entity class names and then assign them a number (their
> > index
> > | in a list). I *really* don't want the entire entity name in the URLs.
> > That
> > | would look kind of cheesy. The way I see it, there are some
options...
> > |
> > | 1. Use a message digest of the entity name. The message digests
would
> > all
> > | be the same length, so we wouldn't have to worry about the URLs
"growing"
> > | when the entity name grew. But, there *is* the chance for digest
> > collisions
> > | (digest of entity name A is the same as digest of entity name B).
> > |
> > | 2. Use the hashCode() of the entity name Strings. Again, we've got
the
> > | possibility for collisions.
> > |
> > | 3. Just use the "simple" entity name (the part of the name after the
last
> > | '.'). I don't think Hibernate requires that you have unique "simple"
> > names
> > | for your entity classes. In practice, this is typically not a
problem.
> > | But, in general, it's not a robust solution.
> > |
> > | 4. Just use the entire entity name and don't worry about all of this!
> > | Users can override it if they wish and how they wish.
> > |
> > | I will be creating a service point which does the translation to/from
the
> > | entity name abbreviation and users can override it if they want.
Which of
> > | these (or if you have other ideas) would be the best "default",
though?
> > The
> > | entity squeezer will detect when there is a collision and either throw
an
> > | exception or print an error message to the logs (haven't decided yet)
to
> > let
> > | you know that you need to come up with a better solution for entity
name
> > | abbreviation.
> > |
> > | James
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
ted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapernate Squeezer...
Posted by James Carman <ja...@carmanconsulting.com>.
That's the way I went with it. I also made a configurable option (set via a
FactoryDefault symbol) that will allow you to tell it whether or not to use
the "short name" of the classes or not. The default is to use the short
name.
-----Original Message-----
From: Ted Steen [mailto:ted.steen@gmail.com]
Sent: Tuesday, June 06, 2006 7:42 PM
To: Tapestry users
Subject: Re: Tapernate Squeezer...
Hi,
I too like the idea of a configuration point for the substitutions.
I can't see a way to convert the name into something more simple,
without the risk of getting collisions and/or somewhat ugly URLs.
With a configuration point one will be able to;
* Get the abbreviation of the entity class to be as small as a single
character
* Have no collisions
* Rename an entity without problems
* "Force"/entices us to configure our own abbreviations, which is
good because otherwise there could be trouble when renaming entities.
2006/6/6, Andreas Andreou <an...@di.uoa.gr>:
> James Carman wrote:
> > Actually, I like Adreas Androu's idea. He said (from the developers
list):
> >
> > "I think I would use the entire entity name enhanced with an optional
> > properties file that would allow users to define substitutions."
> >
> > However, I'm going to go one better. Instead of using a properties
file,
> > I'll create a configuration point for the overrides. That's the
"HiveMind
> > Way."
> >
> hehe! Actually I initially meant to write:
> "I think I would use the entire entity name enhanced with substitutions"
> feeling that you'll make out the missing parts
> > When I said "use the hashCode()", I meant to use the hashCode() of the
> > entity name (a String) itself, not of the entity.
> >
> > -----Original Message-----
> > From: Andreas Bulling [mailto:andreas@phoenix.hadiko.de] On Behalf Of
> > Andreas Bulling
> > Sent: Tuesday, June 06, 2006 8:24 AM
> > To: Tapestry users
> > Subject: Re: Tapernate Squeezer...
> >
> > Hi James,
> >
> > I'd vote for the hashCode() approach, why:
> >
> > 1) It's the approach already used and widely accepted (for example
> > in Hibernate)
> >
> > 2) using Hibernate (which is what Tapernate is dedicated to) you
> > are advised to implement hashCode() and equals() anyway (according
> > to the Hibernate homepage) so it's no additional expense to use
> > it for Tapernate.
> >
> > Just my two cents...
> > Andreas
> >
> > On 06. Jun 2006 - 08:08:21, James Carman wrote:
> > | For those of you who are using Tapernate (and those of you who have
done
> > | something similar in the past), I have a question for you. Currently,
the
> > | Tapernate entity squeezer uses an abbreviation for the class name
> > (basically
> > | an integer). However, I was thinking that this might not be a good
thing
> > | for external links. What would happen if the application is restarted
and
> > | someone has bookmarked an external link? So, I need to come up with a
> > | reliable/repeatable way to "shrink" the entity name down to a small
> > string.
> > | Now, the situation gets even trickier when you consider the fact that
your
> > | application may add entity classes between releases. Therefore, I
can't
> > | just sort the entity class names and then assign them a number (their
> > index
> > | in a list). I *really* don't want the entire entity name in the URLs.
> > That
> > | would look kind of cheesy. The way I see it, there are some
options...
> > |
> > | 1. Use a message digest of the entity name. The message digests
would
> > all
> > | be the same length, so we wouldn't have to worry about the URLs
"growing"
> > | when the entity name grew. But, there *is* the chance for digest
> > collisions
> > | (digest of entity name A is the same as digest of entity name B).
> > |
> > | 2. Use the hashCode() of the entity name Strings. Again, we've got
the
> > | possibility for collisions.
> > |
> > | 3. Just use the "simple" entity name (the part of the name after the
last
> > | '.'). I don't think Hibernate requires that you have unique "simple"
> > names
> > | for your entity classes. In practice, this is typically not a
problem.
> > | But, in general, it's not a robust solution.
> > |
> > | 4. Just use the entire entity name and don't worry about all of this!
> > | Users can override it if they wish and how they wish.
> > |
> > | I will be creating a service point which does the translation to/from
the
> > | entity name abbreviation and users can override it if they want.
Which of
> > | these (or if you have other ideas) would be the best "default",
though?
> > The
> > | entity squeezer will detect when there is a collision and either throw
an
> > | exception or print an error message to the logs (haven't decided yet)
to
> > let
> > | you know that you need to come up with a better solution for entity
name
> > | abbreviation.
> > |
> > | James
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
ted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapernate Squeezer...
Posted by Ted Steen <te...@gmail.com>.
Hi,
I too like the idea of a configuration point for the substitutions.
I can't see a way to convert the name into something more simple,
without the risk of getting collisions and/or somewhat ugly URLs.
With a configuration point one will be able to;
* Get the abbreviation of the entity class to be as small as a single character
* Have no collisions
* Rename an entity without problems
* "Force"/entices us to configure our own abbreviations, which is
good because otherwise there could be trouble when renaming entities.
2006/6/6, Andreas Andreou <an...@di.uoa.gr>:
> James Carman wrote:
> > Actually, I like Adreas Androu's idea. He said (from the developers list):
> >
> > "I think I would use the entire entity name enhanced with an optional
> > properties file that would allow users to define substitutions."
> >
> > However, I'm going to go one better. Instead of using a properties file,
> > I'll create a configuration point for the overrides. That's the "HiveMind
> > Way."
> >
> hehe! Actually I initially meant to write:
> "I think I would use the entire entity name enhanced with substitutions"
> feeling that you'll make out the missing parts
> > When I said "use the hashCode()", I meant to use the hashCode() of the
> > entity name (a String) itself, not of the entity.
> >
> > -----Original Message-----
> > From: Andreas Bulling [mailto:andreas@phoenix.hadiko.de] On Behalf Of
> > Andreas Bulling
> > Sent: Tuesday, June 06, 2006 8:24 AM
> > To: Tapestry users
> > Subject: Re: Tapernate Squeezer...
> >
> > Hi James,
> >
> > I'd vote for the hashCode() approach, why:
> >
> > 1) It's the approach already used and widely accepted (for example
> > in Hibernate)
> >
> > 2) using Hibernate (which is what Tapernate is dedicated to) you
> > are advised to implement hashCode() and equals() anyway (according
> > to the Hibernate homepage) so it's no additional expense to use
> > it for Tapernate.
> >
> > Just my two cents...
> > Andreas
> >
> > On 06. Jun 2006 - 08:08:21, James Carman wrote:
> > | For those of you who are using Tapernate (and those of you who have done
> > | something similar in the past), I have a question for you. Currently, the
> > | Tapernate entity squeezer uses an abbreviation for the class name
> > (basically
> > | an integer). However, I was thinking that this might not be a good thing
> > | for external links. What would happen if the application is restarted and
> > | someone has bookmarked an external link? So, I need to come up with a
> > | reliable/repeatable way to "shrink" the entity name down to a small
> > string.
> > | Now, the situation gets even trickier when you consider the fact that your
> > | application may add entity classes between releases. Therefore, I can't
> > | just sort the entity class names and then assign them a number (their
> > index
> > | in a list). I *really* don't want the entire entity name in the URLs.
> > That
> > | would look kind of cheesy. The way I see it, there are some options...
> > |
> > | 1. Use a message digest of the entity name. The message digests would
> > all
> > | be the same length, so we wouldn't have to worry about the URLs "growing"
> > | when the entity name grew. But, there *is* the chance for digest
> > collisions
> > | (digest of entity name A is the same as digest of entity name B).
> > |
> > | 2. Use the hashCode() of the entity name Strings. Again, we've got the
> > | possibility for collisions.
> > |
> > | 3. Just use the "simple" entity name (the part of the name after the last
> > | '.'). I don't think Hibernate requires that you have unique "simple"
> > names
> > | for your entity classes. In practice, this is typically not a problem.
> > | But, in general, it's not a robust solution.
> > |
> > | 4. Just use the entire entity name and don't worry about all of this!
> > | Users can override it if they wish and how they wish.
> > |
> > | I will be creating a service point which does the translation to/from the
> > | entity name abbreviation and users can override it if they want. Which of
> > | these (or if you have other ideas) would be the best "default", though?
> > The
> > | entity squeezer will detect when there is a collision and either throw an
> > | exception or print an error message to the logs (haven't decided yet) to
> > let
> > | you know that you need to come up with a better solution for entity name
> > | abbreviation.
> > |
> > | James
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
ted
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapernate Squeezer...
Posted by Andreas Andreou <an...@di.uoa.gr>.
James Carman wrote:
> Actually, I like Adreas Androu's idea. He said (from the developers list):
>
> "I think I would use the entire entity name enhanced with an optional
> properties file that would allow users to define substitutions."
>
> However, I'm going to go one better. Instead of using a properties file,
> I'll create a configuration point for the overrides. That's the "HiveMind
> Way."
>
hehe! Actually I initially meant to write:
"I think I would use the entire entity name enhanced with substitutions"
feeling that you'll make out the missing parts
> When I said "use the hashCode()", I meant to use the hashCode() of the
> entity name (a String) itself, not of the entity.
>
> -----Original Message-----
> From: Andreas Bulling [mailto:andreas@phoenix.hadiko.de] On Behalf Of
> Andreas Bulling
> Sent: Tuesday, June 06, 2006 8:24 AM
> To: Tapestry users
> Subject: Re: Tapernate Squeezer...
>
> Hi James,
>
> I'd vote for the hashCode() approach, why:
>
> 1) It's the approach already used and widely accepted (for example
> in Hibernate)
>
> 2) using Hibernate (which is what Tapernate is dedicated to) you
> are advised to implement hashCode() and equals() anyway (according
> to the Hibernate homepage) so it's no additional expense to use
> it for Tapernate.
>
> Just my two cents...
> Andreas
>
> On 06. Jun 2006 - 08:08:21, James Carman wrote:
> | For those of you who are using Tapernate (and those of you who have done
> | something similar in the past), I have a question for you. Currently, the
> | Tapernate entity squeezer uses an abbreviation for the class name
> (basically
> | an integer). However, I was thinking that this might not be a good thing
> | for external links. What would happen if the application is restarted and
> | someone has bookmarked an external link? So, I need to come up with a
> | reliable/repeatable way to "shrink" the entity name down to a small
> string.
> | Now, the situation gets even trickier when you consider the fact that your
> | application may add entity classes between releases. Therefore, I can't
> | just sort the entity class names and then assign them a number (their
> index
> | in a list). I *really* don't want the entire entity name in the URLs.
> That
> | would look kind of cheesy. The way I see it, there are some options...
> |
> | 1. Use a message digest of the entity name. The message digests would
> all
> | be the same length, so we wouldn't have to worry about the URLs "growing"
> | when the entity name grew. But, there *is* the chance for digest
> collisions
> | (digest of entity name A is the same as digest of entity name B).
> |
> | 2. Use the hashCode() of the entity name Strings. Again, we've got the
> | possibility for collisions.
> |
> | 3. Just use the "simple" entity name (the part of the name after the last
> | '.'). I don't think Hibernate requires that you have unique "simple"
> names
> | for your entity classes. In practice, this is typically not a problem.
> | But, in general, it's not a robust solution.
> |
> | 4. Just use the entire entity name and don't worry about all of this!
> | Users can override it if they wish and how they wish.
> |
> | I will be creating a service point which does the translation to/from the
> | entity name abbreviation and users can override it if they want. Which of
> | these (or if you have other ideas) would be the best "default", though?
> The
> | entity squeezer will detect when there is a collision and either throw an
> | exception or print an error message to the logs (haven't decided yet) to
> let
> | you know that you need to come up with a better solution for entity name
> | abbreviation.
> |
> | James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapernate Squeezer...
Posted by James Carman <ja...@carmanconsulting.com>.
Actually, I like Adreas Androu's idea. He said (from the developers list):
"I think I would use the entire entity name enhanced with an optional
properties file that would allow users to define substitutions."
However, I'm going to go one better. Instead of using a properties file,
I'll create a configuration point for the overrides. That's the "HiveMind
Way."
When I said "use the hashCode()", I meant to use the hashCode() of the
entity name (a String) itself, not of the entity.
-----Original Message-----
From: Andreas Bulling [mailto:andreas@phoenix.hadiko.de] On Behalf Of
Andreas Bulling
Sent: Tuesday, June 06, 2006 8:24 AM
To: Tapestry users
Subject: Re: Tapernate Squeezer...
Hi James,
I'd vote for the hashCode() approach, why:
1) It's the approach already used and widely accepted (for example
in Hibernate)
2) using Hibernate (which is what Tapernate is dedicated to) you
are advised to implement hashCode() and equals() anyway (according
to the Hibernate homepage) so it's no additional expense to use
it for Tapernate.
Just my two cents...
Andreas
On 06. Jun 2006 - 08:08:21, James Carman wrote:
| For those of you who are using Tapernate (and those of you who have done
| something similar in the past), I have a question for you. Currently, the
| Tapernate entity squeezer uses an abbreviation for the class name
(basically
| an integer). However, I was thinking that this might not be a good thing
| for external links. What would happen if the application is restarted and
| someone has bookmarked an external link? So, I need to come up with a
| reliable/repeatable way to "shrink" the entity name down to a small
string.
| Now, the situation gets even trickier when you consider the fact that your
| application may add entity classes between releases. Therefore, I can't
| just sort the entity class names and then assign them a number (their
index
| in a list). I *really* don't want the entire entity name in the URLs.
That
| would look kind of cheesy. The way I see it, there are some options...
|
| 1. Use a message digest of the entity name. The message digests would
all
| be the same length, so we wouldn't have to worry about the URLs "growing"
| when the entity name grew. But, there *is* the chance for digest
collisions
| (digest of entity name A is the same as digest of entity name B).
|
| 2. Use the hashCode() of the entity name Strings. Again, we've got the
| possibility for collisions.
|
| 3. Just use the "simple" entity name (the part of the name after the last
| '.'). I don't think Hibernate requires that you have unique "simple"
names
| for your entity classes. In practice, this is typically not a problem.
| But, in general, it's not a robust solution.
|
| 4. Just use the entire entity name and don't worry about all of this!
| Users can override it if they wish and how they wish.
|
| I will be creating a service point which does the translation to/from the
| entity name abbreviation and users can override it if they want. Which of
| these (or if you have other ideas) would be the best "default", though?
The
| entity squeezer will detect when there is a collision and either throw an
| exception or print an error message to the logs (haven't decided yet) to
let
| you know that you need to come up with a better solution for entity name
| abbreviation.
|
| James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapernate Squeezer...
Posted by Andreas Bulling <sp...@phoenix.hadiko.de>.
Hi James,
I'd vote for the hashCode() approach, why:
1) It's the approach already used and widely accepted (for example
in Hibernate)
2) using Hibernate (which is what Tapernate is dedicated to) you
are advised to implement hashCode() and equals() anyway (according
to the Hibernate homepage) so it's no additional expense to use
it for Tapernate.
Just my two cents...
Andreas
On 06. Jun 2006 - 08:08:21, James Carman wrote:
| For those of you who are using Tapernate (and those of you who have done
| something similar in the past), I have a question for you. Currently, the
| Tapernate entity squeezer uses an abbreviation for the class name (basically
| an integer). However, I was thinking that this might not be a good thing
| for external links. What would happen if the application is restarted and
| someone has bookmarked an external link? So, I need to come up with a
| reliable/repeatable way to "shrink" the entity name down to a small string.
| Now, the situation gets even trickier when you consider the fact that your
| application may add entity classes between releases. Therefore, I can't
| just sort the entity class names and then assign them a number (their index
| in a list). I *really* don't want the entire entity name in the URLs. That
| would look kind of cheesy. The way I see it, there are some options...
|
| 1. Use a message digest of the entity name. The message digests would all
| be the same length, so we wouldn't have to worry about the URLs "growing"
| when the entity name grew. But, there *is* the chance for digest collisions
| (digest of entity name A is the same as digest of entity name B).
|
| 2. Use the hashCode() of the entity name Strings. Again, we've got the
| possibility for collisions.
|
| 3. Just use the "simple" entity name (the part of the name after the last
| '.'). I don't think Hibernate requires that you have unique "simple" names
| for your entity classes. In practice, this is typically not a problem.
| But, in general, it's not a robust solution.
|
| 4. Just use the entire entity name and don't worry about all of this!
| Users can override it if they wish and how they wish.
|
| I will be creating a service point which does the translation to/from the
| entity name abbreviation and users can override it if they want. Which of
| these (or if you have other ideas) would be the best "default", though? The
| entity squeezer will detect when there is a collision and either throw an
| exception or print an error message to the logs (haven't decided yet) to let
| you know that you need to come up with a better solution for entity name
| abbreviation.
|
| James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org