The thing is that $user['username'] is the same as $user->username or
$user->get('username') or even the special syntax implemented by
sfDoctrinePlugin for propel compatibility $user->getUsername(). So whether
$user is an array or object, the syntax will work. Also, if you have a
public function getUsername() defined in your User class and you call
$user['username'], it will invoke getUsername()
- Jon
On Fri, Oct 17, 2008 at 3:27 PM, Marijn Huizendveld <
[EMAIL PROTECTED]> wrote:
> Hmm. This is something that is indeed pretty logical and I should have
> known since I read the doctrine blogpost this week about the new scalar
> hydration as well....
> The discussion however remains interesting:-)
>
> Enjoy your weekends.
>
> Marijn
>
> On Oct 17, 2008, at 9:10 PM, Jonathan Wage wrote:
>
> I think you all are confused on the reason. The reason is so that the
> template by default will work with Doctrine array hydration. You can now
> easily change the hydration of the list query to array or record and the
> template will work the same. In Doctrine array hydration is the recommended
> syntax because it works with both hydration types.
>
> - Jon
>
> On Fri, Oct 17, 2008 at 8:39 AM, Marijn Huizendveld <
> [EMAIL PROTECTED]> wrote:
>
>>
>> Hi Thomas,
>>
>> I think you have a valid point but I would suggest to implement the
>> ArrayAccess for those custom properties on the model side for object
>> related data. For other types you could as well fetch the data before
>> passing it to the view.
>>
>> You can have a look at Doctrine_Access to review the methods you
>> would need to override.
>>
>> Marijn
>>
>> On Oct 17, 2008, at 3:21 PM, Thomas Rabaix wrote:
>>
>> >
>> > Hello,
>> >
>> > When i was writing my post I was thinking about all your points. And I
>> > am 80% agree with them.
>> >
>> > But now, template is not always that *easy* and maybe you want to
>> > provide some extra parameter like
>> > <?php $invoice->getTotal(true /* vat = true */) ?> to have a
>> > specific result.
>> >
>> > The final template will be a mix of getter and ArrayAccessor which
>> > is very odd.
>> >
>> > Thomas
>> >
>> > On Fri, Oct 17, 2008 at 3:10 PM, Marijn Huizendveld
>> > <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi Thomas,
>> >>
>> >> I disagree with you, let me explain. If I understand you correctly
>> >> there would be two scenarios. In scenario number one there is a
>> >> front-
>> >> end developer that is developing a template. Given the array data
>> >> access he will think he is working with arrays. Therefor the front-
>> >> end developer will use the methods he is familiar with that work with
>> >> arrays. There is a lot of PHP native documentation for that which
>> >> allows him to, for example, write a simple foreach ($data as $key =>
>> >> $value) { ... } loop with which he creates a much less verbose
>> >> template for a data grid. All without ever consulting the symfony
>> >> documentation which --no offense to the documentation-- I think can
>> >> be pretty scary if you're unfamiliar with frameworks, OOP etc.
>> >> Besides that arrays are a very basic concept so there shouldn't be to
>> >> much new stuff to learn... Right? I think it is harder to explain a
>> >> new front-end developer, who is unknown to OOP, that he receives
>> >> objects, with methods attached to them, which he can call to get his
>> >> data instead of letting him think he is working with arrays... But
>> >> maybe that is something personal.
>> >>
>> >> The other scenario would be someone who is working on more than the
>> >> front-end and who is new to symfony. Although it is indeed important
>> >> that these developers don't get scared away, they should get familiar
>> >> with the ArrayAccessor interface at some point in time since it is
>> >> used on more than just doctrine. These developers, I presume, won't
>> >> have a hard time to grasp the concept of the ArrayAccessor interface
>> >> anyway. Maybe we should add a comment in the generated code
>> >> explaining the fact that it uses the ArrayAccessor interface...
>> >>
>> >> I myself made the move from front-end developer to back-end, although
>> >> that wasn't on the php platform but nevertheless I always liked it if
>> >> data was passed to my end in a way I was familiar with. As front-end
>> >> developer you know that there is more going on and at some point you
>> >> will get curious and try to find out (i.e. hey, this is actually an
>> >> object and it is capable of doing a lot more stuff). But until than I
>> >> think array access is a great way to keep the illusion up that the
>> >> data is just very simply formatted and that there isn't much to it.
>> >>
>> >> That makes 4c in total on this thread;-)
>> >>
>> >> Marijn
>> >>
>> >> On Oct 17, 2008, at 2:43 PM, Thomas Rabaix wrote:
>> >>
>> >>>
>> >>> Hello,
>> >>>
>> >>> I just update the sfDoctrineGenerator, and now the generator use the
>> >>> ArrayAccessor ($object['Attribute']) feature in template, it used to
>> >>> be a standard 'getAttribute'.
>> >>>
>> >>> I am not really sure it is a great idea to use this php feature in
>> >>> template. Most of the people use standard getter and setter, so
>> >>> introducing a new way is not 'bad' but can be very confusing for new
>> >>> symfony developper. And IMO, it will be more harder to debug :
>> >>> "what
>> >>> is that ? an array .... oups no... it is an objet"
>> >>>
>> >>> my 2c
>> >>>
>> >>> --
>> >>> Thomas Rabaix
>> >>> Internet Consultant
>> >>>
>> >>>>
>> >>
>> >>
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Thomas Rabaix
>> > Internet Consultant
>> >
>> > >
>>
>>
>>
>>
>
>
> --
> Jonathan H. Wage
> Open Source Software Developer & Evangelist
> http://www.jwage.com
>
>
>
>
>
> >
>
--
Jonathan H. Wage
Open Source Software Developer & Evangelist
http://www.jwage.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
