On Apr 21, 2007, at 8:19 PM, Jonathan Vanasco wrote:
>> I took a quick pass at a strip() helper it and checked it into SVN.
>> Try it and let me know what you think. (You'll also need to check
>> out
>> the latest Rose::Object to get the new MixIn class.)
>>
>
> Great! Thanks.
Thanks from me
On Apr 20, 2007, at 4:04 PM, John Siracusa wrote:
>
> I took a quick pass at a strip() helper it and checked it into SVN.
> Try it and let me know what you think. (You'll also need to check out
> the latest Rose::Object to get the new MixIn class.)
>
Great! Thanks.
I'm struggling with the sf
On 4/18/07, John Siracusa <[EMAIL PROTECTED]> wrote:
> On 4/18/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
>> On Apr 18, 2007, at 10:22 AM, John Siracusa wrote:
>>> On 4/17/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
Though that can be handled using a strip helper alone too -- we'd
jus
On Apr 18, 2007, at 11:58 AM, John Siracusa wrote:
>
> Well, lemme implement it and you can try it and tell me how it works
> for you. I'll try to get it done this week.
fair enough :)
I should have the object_tree stuff done by friday/monday.
I had to put this stuff off for a few days to deal
On 4/18/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
> On Apr 18, 2007, at 10:22 AM, John Siracusa wrote:
>> On 4/17/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
>>> Though that can be handled using a strip helper alone too -- we'd just need
>>> an unstrip() function that builds back in a db
On Apr 18, 2007, at 10:22 AM, John Siracusa wrote:
> On 4/17/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
>> Though that can be handled using a strip helper alone too -- we'd
>> just need an unstrip() function that builds back in a db object and
>> metadata
>
> I don't think that'd be necessar
On 4/17/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
> Though that can be handled using a strip helper alone too -- we'd
> just need an unstrip() function that builds back in a db object and
> metadata
I don't think that'd be necessary. The meta and db attributes would
re-materialize on demand
On Apr 17, 2007, at 4:55 PM, John Siracusa wrote:
> I actually plan to make a strip() helper that would break all links
> with metadata, drop the db object, etc. Basically, making an object
> ready for sane serialization with Storable (or whatever).
>> the point of all this is to create cachab
On 4/17/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
> i've also started playing around with something that will make you
> cringe, or perhaps chime in with suggestions and enthusiasm !
>
> object_tree_as_storable
> object_tree_from_storable
>
> right now they're being made trave
On Apr 16, 2007, at 12:22 PM, John Siracusa wrote:
>
> How about "object_tree" instead of just "object" to better indicate
> that
> input/output isn't just a long object:
>
> $yaml = $o->object_tree_as_yaml;
> $o->init_with_yaml_object_tree($yaml);
>
> Actually, depending on how you plan
On 4/16/07 12:22 PM, John Siracusa wrote:
> How about "object_tree" instead of just "object" to better indicate that
> input/output isn't just a long object:
^
Er, "lone"
-John
-
This SF.net e
On 4/16/07 12:07 PM, Jonathan Vanasco wrote:
> i'm thinking of the following naming scheme:
> Helpers::object_as_yaml
> Helpers::init_with_yaml_object
>
> ( using the term 'object' as it is a deep 'loaded related' object,
> not a flat column/pairs )
How about "object_tree" instead of just "object
I'm going to need to cache my objects into memcached , and looking
for options.
the quick&dirty way would be to just use storable. i think
cache::memcached should be able to bring back the entire object
structure -- including nested objects
has anyone done this? pros / cons ?
my other op
13 matches
Mail list logo
