h***@public.gmane.org
2003-01-02 15:37:02 UTC
I am concerned about the complexity and expense of maintaining copies, however
there is an element of "correctness" in creating these copies; it ensures that
single-server and clustered behavior is the same ... just as a backup service
in a cluster receives only copies of persistent properties, so will a single-
server; it ensures that the copy is the same for both.
There's still room to cheat (especially by changing properties of objects
stored inside collections, when the collections are persistent properties), but
it stands out more, and the behavior and timing is easier to describe.
Given that the vast majority of persistant properties will be String, Date,
boolean, int, etc. (that is, easily identifyable immutables), the cost is
actually not so great.
The second-worst case in an object that is merely Serializable, since (deep)
copying via Serialization is pretty darn expensive.
The worst case is getting an exception because a particular object type can't
be copied.
I'll noodle on the idea of a "peer" that stores persistant state. I'm not
immediately seeing a way to do it that doesn't break most existing
applications, and I'm concerned that creating new pages will involve a page
spec, template and TWO classes (one for logic, one for data storage). Seems
less natural to me.
Again, on the applications I've worked on, persistent properties tend to be
pretty rare and, when present, are immutable objects. On the other hand, there
are lots of people out there with much more experience actually building
Tapestry applications than I do (perplexing, isn't it!).
--
hlship-***@public.gmane.org
http://tapestry.sf.net
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
there is an element of "correctness" in creating these copies; it ensures that
single-server and clustered behavior is the same ... just as a backup service
in a cluster receives only copies of persistent properties, so will a single-
server; it ensures that the copy is the same for both.
There's still room to cheat (especially by changing properties of objects
stored inside collections, when the collections are persistent properties), but
it stands out more, and the behavior and timing is easier to describe.
Given that the vast majority of persistant properties will be String, Date,
boolean, int, etc. (that is, easily identifyable immutables), the cost is
actually not so great.
The second-worst case in an object that is merely Serializable, since (deep)
copying via Serialization is pretty darn expensive.
The worst case is getting an exception because a particular object type can't
be copied.
I'll noodle on the idea of a "peer" that stores persistant state. I'm not
immediately seeing a way to do it that doesn't break most existing
applications, and I'm concerned that creating new pages will involve a page
spec, template and TWO classes (one for logic, one for data storage). Seems
less natural to me.
Again, on the applications I've worked on, persistent properties tend to be
pretty rare and, when present, are immutable objects. On the other hand, there
are lots of people out there with much more experience actually building
Tapestry applications than I do (perplexing, isn't it!).
--
hlship-***@public.gmane.org
http://tapestry.sf.net
hi,
I think exposing the pooling that has to happen inside tapestry to the
average component developer is a mistake. It just opens up a way of
shooting yourself in the foot, while giving very little advantage to app
developers in general. And it seems now in order to make the semantics
less confusing, you have to add more expensive and complicated behavior
(copying) to the framework... Now I do agree that the pooling of
expensive resources (templates, bindings, whatever else) is a goood
thing... however, i would separate it in two: make components non-pooled
and recreated all the time, and separate out the heavyweight portion into
another class that does need to know about pooling. The lightweight
component should delegate to the pooled instance when needed (Tapestry
should estabilish the association between it and the peer).
Component c = ... // new instance
ComponentPeer p = pool.getPeer(c);
c.setPeer( p );
// perform request...
p.detach()
c = null; // just forget about it...
pool.returnPeer(p);
I think this would make developers have to think about a lot less
"issues" that really have nothing to do with their application logic,
only how the framework is built. Writing components would become more
natural - you can use regular constructors and forget about detach and
it's sideffects.
i hope this doesnt sound much sillier or less efficient than an intricate
copying solution with special handling for immutables :)
best regards,
viktor
--
--
http://fastmail.fm - Email service worth paying for. Try it for free
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib
-------------------------------------------------------The basic types, such as String, Number, Boolean work fine. It
differentiates between mutable and immutable objects. Immutable objects
are
String, Number, Boolean, java.util.Date (which is slightly fudging), Enum
and anything marked as IImmutable (a new marker interface for immutable
objects).
Mutable objects are tougher since the persistance wants to keep an
isolateddifferentiates between mutable and immutable objects. Immutable objects
are
String, Number, Boolean, java.util.Date (which is slightly fudging), Enum
and anything marked as IImmutable (a new marker interface for immutable
objects).
Mutable objects are tougher since the persistance wants to keep an
copy of properties. That is, fireObservedChange() results in a copy
beingmade, and when a page is rolled back in a later request cycle, a copy (of
the copy) is made.
The problem is handling the copying of values. At best, its going to do
athe copy) is made.
The problem is handling the copying of values. At best, its going to do
shallow copy. As a last resort, Serializable objects are serialized and
deserialzed (to make a deep copy).
deserialzed (to make a deep copy).
average component developer is a mistake. It just opens up a way of
shooting yourself in the foot, while giving very little advantage to app
developers in general. And it seems now in order to make the semantics
less confusing, you have to add more expensive and complicated behavior
(copying) to the framework... Now I do agree that the pooling of
expensive resources (templates, bindings, whatever else) is a goood
thing... however, i would separate it in two: make components non-pooled
and recreated all the time, and separate out the heavyweight portion into
another class that does need to know about pooling. The lightweight
component should delegate to the pooled instance when needed (Tapestry
should estabilish the association between it and the peer).
Component c = ... // new instance
ComponentPeer p = pool.getPeer(c);
c.setPeer( p );
// perform request...
p.detach()
c = null; // just forget about it...
pool.returnPeer(p);
I think this would make developers have to think about a lot less
"issues" that really have nothing to do with their application logic,
only how the framework is built. Writing components would become more
natural - you can use regular constructors and forget about detach and
it's sideffects.
i hope this doesnt sound much sillier or less efficient than an intricate
copying solution with special handling for immutables :)
best regards,
viktor
--
--
http://fastmail.fm - Email service worth paying for. Try it for free
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf