Yes, the current implementation will probably end up being the default behavior: serialize everything, and make all simple variables in the "this" and "variables" scopes searchable. Later we can add some mechanism to limit and control this; adding new attributes to CFPROPERTY seems like a good candidate (you've newly joined the CFML Advisory Committee, right? maybe you could run this by them?).
Not only is GAE really cool all by itself, but the ability to store CFCs directly within the datastore without resorting to an ORM layer or SQL is really great. It would be nice if you could use the GAE datastore (or something like it) for "local" applications. Vince On Jun 2, 12:11 pm, "Peter J. Farrell" <[email protected]> wrote: > > Thanks for your response Vince. While I haven't had time to play with > this stuff, I'm an totally amazed by it. > > Anyways, I'm thinking that cfproperty will be a great place to indicate > what should be serialized to the datastore. Maybe it should proposed > that there a serialize="all|none" on cfcomponent while cfproperty can > make it more granular based. > > Totally understand the manual part of removing the components / data > that should not be serialized right now. Just thinking out loud about > using cfproperty to help provide metadata on the > serialization/deserialization process. > > Best, > .Peter > --~--~---------~--~----~------------~-------~--~----~ Open BlueDragon Public Mailing List http://groups.google.com/group/openbd?hl=en official site @ http://www.openbluedragon.org/ !! save a network - trim replies before posting !! -~----------~----~----~----~------~----~------~--~---
