I was poking around the new MVC classes and apparently the setState() of JModel now only supports a JRegistry object as an argument. Not only that, it does not support "merging" another registry object to append keys to the state.
In the old MVC the controller has been able to set/modify state values in the model by calling setState() with two parameters (key/value), this is no longer possible and would result in the controller having to 1. get the registry object, 2. set the value, 3. set the registry object back in the model to be able to do this.
So to sum it all up, I have two questions.
1. Is there a particular reason why the setState() function can't support both setting a new JRegistry object, and setting a new value in the registry object based on a key/value pair?
2. While I do get that type hinting is the new cool stuff in the platform, does it make sense to force the object type in this case , thus making the implementation less flexible for people that want to use the JModel interface ?
> I was poking around the new MVC classes and apparently the setState() of JModel now only supports a JRegistry object as an argument. Not only that, it does not support "merging" another registry object to append keys to the state.
> In the old MVC the controller has been able to set/modify state values in the model by calling setState() with two parameters (key/value), this is no longer possible and would result in the controller having to 1. get the registry object, 2. set the value, 3. set the registry object back in the model to be able to do this.
> So to sum it all up, I have two questions.
> 1. Is there a particular reason why the setState() function can't support both setting a new JRegistry object, and setting a new value in the registry object based on a key/value pair?
> 2. While I do get that type hinting is the new cool stuff in the platform, does it make sense to force the object type in this case , thus making the implementation less flexible for people that want to use the JModel interface ?
Personally I would probably prefer something like this
public function setState($name, $value = null)
{
if($name instanceof JRegistry)
{
$this->state->merge($name);
}
else
{
$this->state->set($name, $value);
}
}
But that does create an ambiguous argument name since the first argument can both be a path and an object. With maybe an optional argument whether to merge or just replace the whole registry object. Quite possibly it would be better to implement two methods in the interface. And of course their getters respectively.
public function setState($name, $value);
public function setStore(JRegistry $object);
This would allow proper type hinting where needed, and make the behavior consistent to what a lot of software already out there expects, being able to set values in the state using setState()
On Wednesday, 25 July 2012 16:52:36 UTC+2, Louis Landry wrote:
> I've been struggling with the same things Rune. It may have simply been a > case of over zealous simplification.
> L
> Sent from my iPad
> On Jul 25, 2012, at 7:03 AM, Rune V. Sjøen <rvsj...@gmail.com> wrote:
> > Hello all,
> > I was poking around the new MVC classes and apparently the setState() of > JModel now only supports a JRegistry object as an argument. Not only that, > it does not support "merging" another registry object to append keys to the > state.
> > In the old MVC the controller has been able to set/modify state values > in the model by calling setState() with two parameters (key/value), this is > no longer possible and would result in the controller having to 1. get the > registry object, 2. set the value, 3. set the registry object back in the > model to be able to do this.
> > So to sum it all up, I have two questions.
> > 1. Is there a particular reason why the setState() function can't > support both setting a new JRegistry object, and setting a new value in the > registry object based on a key/value pair?
> > 2. While I do get that type hinting is the new cool stuff in the > platform, does it make sense to force the object type in this case , thus > making the implementation less flexible for people that want to use the > JModel interface ?
That's actually not a bad idea Rune. I'd like to hear what others think on
this. It may be just as easy if you are willing to just put together a
quick pull request for the basics here and we can discuss the details in
the PR discussion thread. Whatever works for you.
Cheers.
- Louis
On Wed, Jul 25, 2012 at 9:04 AM, Rune V. Sjøen <rvsj...@gmail.com> wrote:
> But that does create an ambiguous argument name since the first argument
> can both be a path and an object. With maybe an optional argument whether
> to merge or just replace the whole registry object. Quite possibly it would
> be better to implement two methods in the interface. And of course their
> getters respectively.
> public function setState($name, $value);
> public function setStore(JRegistry $object);
> This would allow proper type hinting where needed, and make the behavior
> consistent to what a lot of software already out there expects, being able
> to set values in the state using setState()
> - Rune
> On Wednesday, 25 July 2012 16:52:36 UTC+2, Louis Landry wrote:
>> I've been struggling with the same things Rune. It may have simply been a
>> case of over zealous simplification.
>> L
>> Sent from my iPad
>> On Jul 25, 2012, at 7:03 AM, Rune V. Sjøen <rvsj...@gmail.com> wrote:
>> > Hello all,
>> > I was poking around the new MVC classes and apparently the setState()
>> of JModel now only supports a JRegistry object as an argument. Not only
>> that, it does not support "merging" another registry object to append keys
>> to the state.
>> > In the old MVC the controller has been able to set/modify state values
>> in the model by calling setState() with two parameters (key/value), this is
>> no longer possible and would result in the controller having to 1. get the
>> registry object, 2. set the value, 3. set the registry object back in the
>> model to be able to do this.
>> > So to sum it all up, I have two questions.
>> > 1. Is there a particular reason why the setState() function can't
>> support both setting a new JRegistry object, and setting a new value in the
>> registry object based on a key/value pair?
>> > 2. While I do get that type hinting is the new cool stuff in the
>> platform, does it make sense to force the object type in this case , thus
>> making the implementation less flexible for people that want to use the
>> JModel interface ?
> But that does create an ambiguous argument name since the first argument
> can both be a path and an object. With maybe an optional argument whether
> to merge or just replace the whole registry object. Quite possibly it would
> be better to implement two methods in the interface. And of course their
> getters respectively.
> public function setState($name, $value);
> public function setStore(JRegistry $object);
> This would allow proper type hinting where needed, and make the behavior
> consistent to what a lot of software already out there expects, being able
> to set values in the state using setState()
> - Rune
> On Wednesday, 25 July 2012 16:52:36 UTC+2, Louis Landry wrote:
>> I've been struggling with the same things Rune. It may have simply been a
>> case of over zealous simplification.
>> L
>> Sent from my iPad
>> On Jul 25, 2012, at 7:03 AM, Rune V. Sjøen <rvsj...@gmail.com> wrote:
>> > Hello all,
>> > I was poking around the new MVC classes and apparently the setState()
>> of JModel now only supports a JRegistry object as an argument. Not only
>> that, it does not support "merging" another registry object to append keys
>> to the state.
>> > In the old MVC the controller has been able to set/modify state values
>> in the model by calling setState() with two parameters (key/value), this is
>> no longer possible and would result in the controller having to 1. get the
>> registry object, 2. set the value, 3. set the registry object back in the
>> model to be able to do this.
>> > So to sum it all up, I have two questions.
>> > 1. Is there a particular reason why the setState() function can't
>> support both setting a new JRegistry object, and setting a new value in the
>> registry object based on a key/value pair?
>> > 2. While I do get that type hinting is the new cool stuff in the
>> platform, does it make sense to force the object type in this case , thus
>> making the implementation less flexible for people that want to use the
>> JModel interface ?
I prefer Andrew's nomenclature. To me it is more readily apparent how the different methods are to be used, and I like that "State" is consistent across the method names.
