[TYPO3-mvc] Few proposals for mvc_extjs view branch

[Dmitri Pisarev]

Hey Dennis!
On 09.06.2010 16:35, Dennis Ahrens wrote:
> Hi Dmitri,
>
> I've also thought about this in the past. In our last project the gui
> code becomes really unclean in the end. That's why i'm integrating
> Ext.Direct (prototype is nearly finished).
> I think ViewHelpers should only be used for js code which is related to
> informations based on the PHP Domain Model, like the
> JsonReaderViewHelper and the ColumnDefinitionViewHelper.
I agree with that, and that's how I use it mostly.
>
> I also think that the SettingsViewHelper is handy and useful.
Actually I have already started to write the same viewHelper, before I 
spotted yours. I also use it now.
>
> The other stuff contained in the jsCode package may become deprecated,
> if we find a better solution.
Well, most of stuff in jsCode IS related to domain model.
>
> In our new project i'd like to have another gui architecture - with
> classes which are responsible for (extjs) object creation and
> application flow inside the gui.
It's a mystery for me, how to write gui for large applications so it 
shall remain clean. Do you think it's not possible to do it in pure JS, 
with only domain model related stuff generated through the viewHelpers?
Anyway, this is very important topic, and very relevant to me, let's see 
if I can provide some feedback on this.
BTW, the way you extend ExtJS classes for configuration, seems to be not 
a very good architecture, ExtJS specialist suggest to use factories for 
that, and only use Extend when you change some functionality.
>
>> My proposal is to do it more generally, I see two basic aproaches:
>> 1)See if the parameter is registred in fluid, if yes the treat it
>> accordingly, is not the just do ->setRaw('paramName', $paramValue).
>> But I don't know if it's possible in fluid to pass unregistered
>> parameters.
>> 2)For every view helper introduce an array() property which would
>> consist of 'paramName'=>'paramValue' pairs. As far as I can see, this
>> implementation has almost no drawbacks, because you surely know what
>> to expect from this kind of property, and use it on your own risk.
> Unregistered parameters are not possible AFAIK. The second solution
> feels good i think and may be used as an alternative.
>
> Another approach may be annotation based code generation. Think about
> somthing like this:
>
> ViewHelper-Code:
> <ext:includeDomainAnnotations />
>
> Class Annotation:
> /**
> * [...]
> * @extjs form gridcolumn
> */
>
> Variable Annotation
> /**
> * [...]
> * @validate StringLength(minimum = 2, maximum = 80)
> * @form <configuartion>
> * @gridcolumn <configuration>
> */
>
> Maybe it is senseful to inculde information from TCA, too.
I didn't quite get this part. Annotations to what class are those? Some 
viewhelper?

And one more note, your viewhelper classes should be more easy to 
extend. For example, to add the 'total' parameter to your 
StoreReadResponseViewHelper.php class, I had to rewrite the whole class, 
there was not much to extend. In typo3v4 era, there were hooks, now what?=)

With a great appreciation of your work,
Dmitri.