[TYPO3-50-general] Beer3 - Array Syntax and View Helpers

[Sebastian Kurfürst]

Hey Bastian,

> I prefer <f3:loop over="..." as="..."> over the for each syntax, as  
> this
> reminds me too much of the PHP foreach, though it might be different
> (see below). But I guess, both is ok!
Yep, I guess this is an issue where people have 50/50 opinions about  
it. Maybe we should do a public poll :-)

> Regarding links and URIs (we decided to stick with "URI" instead of
> "URL" in FLOW3 context):
> <f3:uri.linkTo action="...
> and
> <f3:uri.uriFor action="...
OK, sounds nice. We can use this as well.

> Don't know.. I'm not perfectly happy with this either, but I think  
> it's
> already a bit more consistent.
Right :-) Let's give us some more time thinking about it!

> - Form (input, select, submit, ....) - That's probably provided by  
> some
> form engine..
exactly, I think so too.

> - Email (that's probably part of the URI helper)
Yes.

> - L10N... black hole ;)
+1


>  General formatters (raw, integer, float, rich text) -  by default
> {post.title} should be htmlspecialchar'ed of course.
Hmm, that is a difficult issue. In case you use {post.title} as a  
parameter, no htmlspecialcharing should be done, right?

However, while I think about it - this could nicely work :-) 

> - Grid <f3:grid headers="{col1:'POST ID', col2:'POST TITLE'}"
> columns="{col1:'id', col2:'title'}" for="{posts}" />  ...something  
> like
> that - Or at least some general table helper.
I'd call this a "widget", no?

> <f3:loop over="{posts}" as="post" key="index" counter="i"...
+1

> And all tag based helpers (image, link, ...) should allow all/most of
> the existing (X)HTML attributes like:
This was planned anyways, I just did not implement it yet or write it  
down :-)

> <f3:image width="..." maxWidth="..." title="..." rel="..." ...
>
> Even though that would bloat the view helpers quite a bit (another
> reason why we should use view helper classes rather then methods to be
> able to extend some abstract "tagbased" view helper).
No it would not bloat the view helpers too much  I think. Essentially  
it will be just a single helper method which can be put there via  
inheritance.
Anyways I still see your point - and I think we should still see which  
method of creating a view helper works out best for us :-) Let's first  
try to keep it simple and lean (= multiple helpers per class), and if  
we notice this gets too crowded or the implementation is not nice, we  
should change it to one class per helper. Deal? :-)

> I'll be quite busy with the Routing until the first release. But I'll
> happily help wherever I can!
Great - thanks Bastian :-) Actually I still hoped some more people  
join in!

Greets,
Sebastian