Modifying Collection and Entity so that you can pass in $options if you ... #757

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
4 participants
Contributor

coogle commented Dec 20, 2012

...so desire. This allows you to for example pass in custom data handlers if desired for specific object handling when calling Entity->data()

This is useful because if you want to do something like allow DateTime objects to be used for 'date' fields, this can be done rather easily with a custom MongoDb Schema object and mostly works. Since Entities just push/pull data from arrays without caring what the data is this works as well.

The problem comes in when you try to do something like use validates(). At this point, the data is unceremoniously converted to an array using data() which crushes that DateTime object into an array with keys. Without this patch, you couldn't modify validates() to pass in a custom handler to address this issue (and thus keep the DateTime object in tact).

By no means is this a fix for what I think is a bigger issue that Entities don't allow you to manage your own custom types more effectively, but it does make sense to me that if the call-chain allows you to pass a handlers option in all the way up to data(), data() should as well. It's not an API everyone will use, but it certainly should be available to allow people to dictate exactly what they are getting back when they call data().

@coogle coogle Modifying Collection and Entity so that you can pass in $options if y…
…ou so desire. This allows you to

for example pass in custom data handlers if desired for specific object handling when calling Entity->data()
348231d
Owner

nateabele commented Dec 20, 2012

This came up once before, and we decided against it, because data() is a standard interface across a few different objects. The whole point of it is that's what you call when all you want to get back are arrays and scalars. If you want to pass in options, just call ->to('array') instead. Where Entity and Collection are concerned, they're identical.

This is useful because if you want to do something like allow DateTime objects to be used for 'date' fields

This is one of the exact use-cases being addressed by the Schema class in the next version.

Without this patch, you couldn't modify validates()

If you're modifying validates() anyway, again, just have it call to('array') instead of data(). The larger issue here is that the Validator class currently only validates arrays, which is something we're working on as well, since transforming something to an array when you want to validate it as an object anyway is kind of pointless.

Contributor

coogle commented Dec 20, 2012

On Thu, Dec 20, 2012 at 11:33 AM, Nate Abele notifications@github.comwrote:

This came up once before, and we decided against it, because data() is a
standard interface across a few different objects. The whole point of it is
that's what you call when all you want to get back are arrays and scalars.
If you want to pass in options, just call ->to('array') instead. Where
Entity and Collection are concerned, they're identical.

This is useful because if you want to do something like allow DateTime
objects to be used for 'date' fields

This is one of the exact use-cases being addressed by the Schema class in
the next version.

Is Schema incomplete development wise? In the latest dev creating a schema
and adding a DateTime type doesn't actually work. Is there a mechanism
currently for example that just let's me do:

$entity->date = new \DateTime()

and either

  1. Let's me validate $entity->date (presently Validator::check() casts the
    DateTime to an array which breaks things)
  2. Automatically upon assign convert the DateTime object to at the very
    least a timestamp?

Perhaps I'm missing the right answer here ..

John

Owner

nateabele commented Dec 21, 2012

Is Schema incomplete development wise?

Heh, as I know you're aware, Open Source projects don't have a standard definition for that. It was feature-complete for the last release, and will be feature-complete in the next release when we're done adding things to it. ;-)

In the latest dev creating a schema and adding a DateTime type doesn't actually work.

Correct, this wasn't contemplated until after the Schema class was initially drafted.

Is there a mechanism currently for example that just let's me do[...]

Validator doesn't actually do the array-casting. The reason why I suggested just using to('array') with the appropriate options instead of patching data() was because it sounds like you've already overridden Model::validates() (which is where the data actually gets cast to an array). You can literally copy the core implementation, and just change $entity->data() to $entity->to('array', $options).

Automatically upon assign convert the DateTime object to at the very least a timestamp?

Not totally sure what you're after here. The framework doesn't currently understand how to convert DateTime objects to MongoDates, but neither the solution I suggested, nor your data() patch will make any difference where that's concerned.

Hopefully that does more to clear things up than create confusion. Let me know if you have any follow-up questions.

Contributor

coogle commented Dec 21, 2012

No I was actually trying to avoid extending core objects if possible,
because doing so tends to break things when you upgrade between releases.
I'm aware Validator doesn't actually cast it, but it does however use
data() -- I do see your point about I could always change that to use to()
instead, tho.

You've answered my question tho, thanks. I was hoping there was a
relatively painless way to just do this..

$entity->mydate = new \DateTime()
$entity->mydate->setTimezone(new \DateTimeZone('EST'));
$entity->validates(); // passes the instance of \DateTime() into my
validation routine for 'mydate'
$entity->save();

$id = $entity->_id;

$entity = Foo::find(array('conditions' => array('_id' => $id)));
$entity->mydate->format('ga');

...where the framework itself would accept a Datetime, save it properly as
a MongoDate/timestamp, then re-create the datetime after the fact
transparently. This however, cannot be done as far as I can see without
completely forking aspects of behavior.

John

On Thu, Dec 20, 2012 at 10:25 PM, Nate Abele notifications@github.comwrote:

Is Schema incomplete development wise?

Heh, as I know you're aware, Open Source projects don't have a standard
definition for that. It was feature-complete for the last release, and will
be feature-complete in the next release when we're done adding things to
it. ;-)

In the latest dev creating a schema and adding a DateTime type doesn't
actually work.

Correct, this wasn't contemplated until after the Schema class was
initially drafted.

Is there a mechanism currently for example that just let's me do[...]

Validator doesn't actually do the array-casting. The reason why I
suggested just using to('array') with the appropriate options instead of
patching data() was because it sounds like you've already overridden
Model::validates() (which is where the data actually gets cast to an
array). You can literally copy the core implementation, and just change
$entity->data() to $entity->to('array', $options).

Automatically upon assign convert the DateTime object to at the very least
a timestamp?

Not totally sure what you're after here. The framework doesn't currently
understand how to convert DateTime objects to MongoDates, but neither the
solution I suggested, nor your data() patch will make any difference
where that's concerned.

Hopefully that does more to clear things up than create confusion. Let me
know if you have any follow-up questions.


Reply to this email directly or view it on GitHubhttps://github.com/UnionOfRAD/lithium/pull/757#issuecomment-11601582.

Owner

gwoo commented Dec 21, 2012

Would applying a filter to validated help?

On Dec 20, 2012, at 10:09 PM, coogle notifications@github.com wrote:

No I was actually trying to avoid extending core objects if possible,
because doing so tends to break things when you upgrade between releases.
I'm aware Validator doesn't actually cast it, but it does however use
data() -- I do see your point about I could always change that to use to()
instead, tho.

You've answered my question tho, thanks. I was hoping there was a
relatively painless way to just do this..

$entity->mydate = new \DateTime()
$entity->mydate->setTimezone(new \DateTimeZone('EST'));
$entity->validates(); // passes the instance of \DateTime() into my
validation routine for 'mydate'
$entity->save();

$id = $entity->_id;

$entity = Foo::find(array('conditions' => array('_id' => $id)));
$entity->mydate->format('ga');

...where the framework itself would accept a Datetime, save it properly as
a MongoDate/timestamp, then re-create the datetime after the fact
transparently. This however, cannot be done as far as I can see without
completely forking aspects of behavior.

John

On Thu, Dec 20, 2012 at 10:25 PM, Nate Abele notifications@github.comwrote:

Is Schema incomplete development wise?

Heh, as I know you're aware, Open Source projects don't have a standard
definition for that. It was feature-complete for the last release, and will
be feature-complete in the next release when we're done adding things to
it. ;-)

In the latest dev creating a schema and adding a DateTime type doesn't
actually work.

Correct, this wasn't contemplated until after the Schema class was
initially drafted.

Is there a mechanism currently for example that just let's me do[...]

Validator doesn't actually do the array-casting. The reason why I
suggested just using to('array') with the appropriate options instead of
patching data() was because it sounds like you've already overridden
Model::validates() (which is where the data actually gets cast to an
array). You can literally copy the core implementation, and just change
$entity->data() to $entity->to('array', $options).

Automatically upon assign convert the DateTime object to at the very least
a timestamp?

Not totally sure what you're after here. The framework doesn't currently
understand how to convert DateTime objects to MongoDates, but neither the
solution I suggested, nor your data() patch will make any difference
where that's concerned.

Hopefully that does more to clear things up than create confusion. Let me
know if you have any follow-up questions.


Reply to this email directly or view it on GitHubhttps://github.com/UnionOfRAD/lithium/pull/757#issuecomment-11601582.


Reply to this email directly or view it on GitHub.

Contributor

coogle commented Dec 21, 2012

If it helps it'll only help by totally throwing away the native
implementation and using the filter to replace it at which point it makes
more sense to just extend the class.

On Fri, Dec 21, 2012 at 11:35 AM, gwoo notifications@github.com wrote:

Would applying a filter to validated help?

On Dec 20, 2012, at 10:09 PM, coogle notifications@github.com wrote:

No I was actually trying to avoid extending core objects if possible,
because doing so tends to break things when you upgrade between
releases.
I'm aware Validator doesn't actually cast it, but it does however use
data() -- I do see your point about I could always change that to use
to()
instead, tho.

You've answered my question tho, thanks. I was hoping there was a
relatively painless way to just do this..

$entity->mydate = new \DateTime()
$entity->mydate->setTimezone(new \DateTimeZone('EST'));
$entity->validates(); // passes the instance of \DateTime() into my
validation routine for 'mydate'
$entity->save();

$id = $entity->_id;

$entity = Foo::find(array('conditions' => array('_id' => $id)));
$entity->mydate->format('ga');

...where the framework itself would accept a Datetime, save it properly
as
a MongoDate/timestamp, then re-create the datetime after the fact
transparently. This however, cannot be done as far as I can see without
completely forking aspects of behavior.

John

On Thu, Dec 20, 2012 at 10:25 PM, Nate Abele notifications@github.comwrote:

Is Schema incomplete development wise?

Heh, as I know you're aware, Open Source projects don't have a
standard
definition for that. It was feature-complete for the last release, and
will
be feature-complete in the next release when we're done adding things
to
it. ;-)

In the latest dev creating a schema and adding a DateTime type doesn't
actually work.

Correct, this wasn't contemplated until after the Schema class was
initially drafted.

Is there a mechanism currently for example that just let's me do[...]

Validator doesn't actually do the array-casting. The reason why I
suggested just using to('array') with the appropriate options instead
of
patching data() was because it sounds like you've already overridden
Model::validates() (which is where the data actually gets cast to an
array). You can literally copy the core implementation, and just
change
$entity->data() to $entity->to('array', $options).

Automatically upon assign convert the DateTime object to at the very
least
a timestamp?

Not totally sure what you're after here. The framework doesn't
currently
understand how to convert DateTime objects to MongoDates, but neither
the
solution I suggested, nor your data() patch will make any difference
where that's concerned.

Hopefully that does more to clear things up than create confusion. Let
me
know if you have any follow-up questions.


Reply to this email directly or view it on GitHub<
https://github.com/UnionOfRAD/lithium/pull/757#issuecomment-11601582>.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com/UnionOfRAD/lithium/pull/757#issuecomment-11619144.

Member

blainesch commented Dec 21, 2012

You could extend the class, but that's not the 'lithium' way of changing a filterable method. Some filters do break the chain and just completely overwrite the current implementation, I see nothing wrong with that.

coogle closed this Dec 26, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment