[TYPO3-ect] Close to final alpha - Roadmap

[Fabien Udriot]

Thanks for the quick answer (as usually) and the highlights.

> As you see I scheduled an example plugin with strict MVC style in 
> bananas. Lib/div itself is more finegrained than simple MVC. (Would 
> you place the RTE transformations into model or view?)

Well... according to the MVC definition, it seems to me to be a view's 
task. But this being said, it is not a problem for me if it is elsewhere...

The view definition : renders the model into a form suitable for 
interaction, typically a user interface element.

> A while ago I already hinted, that I would strip the TS configurable 
> PoP from lib/div for some reasons and move it to an addon_extension.
> 
Yes, I remember. A "lib__pop" ;)

As feedback, I would like to mention that I found this concept very nice 
and I enjoyed to use it in my extensions. I didn't meet any difficulties 
to use it. On the contrary ! So, I'm looking forward to see the concept 
re-implemented back as extension. Will it be challenging ?

 > Well, a strict rule for file organisation is not required to use
 > lib/div. There are many good ways to organize the directories. It
 > depends on the targets of your project on which directory level you
 > want to separate model and view.
Perhaps... But I consider a strength in a community project when we have 
clear guide lines and conventions that every one is able to understand 
and follow. What a waste of time to dive into the developer's logic 
again and again instead of having a common logic !

 >> If I understand well, bananas will be completed with 3 others
 >> folders which will present other programming coding style. (php4 -
 >> smarty - mvc)
 >
 > Right. I use the different styles as top level of the directory
 > structure to underline that they show very different alternatives.
A warm welcome to other examples... I tried to make my extension 
re-working without success : when I put the controller on the root path 
of the extension, I get a correct output, but when I place it in a 
sub-directory, the defaultAction() is not exectuted with no error's 
message. Maybe the point is that the setup.txt must be in the same 
directory as the controller. I give up for tonight !

cheers,

Fabien

> Hi Fabien,
> 
> thank you for reflecting the result of the developing process. On the
>  first glance bananas will look very different again, but it isn't 
> that much altered as it may seem.
> 

> 
>> Hi every one,
>> 
>> I did some testing with the subversion's lib and I feel quite 
>> confused at the moment. It seems to me that we have droped the 
>> concept of MVC.
> 
> As you see I scheduled an example plugin with strict MVC style in 
> bananas. Lib/div itself is more finegrained than simple MVC. (Would 
> you place the RTE transformations into model or view?)
> 
>> Furthermore, I don't see in bananas the PAC's concept any more
> 
> PAC and PoP is not the same but related:
> 
> * PAC (Hierarchical MVC) teaches, that there is a tree of nodes, 
> where each node has all a model, a view and a controller. It's still 
> there, for example in form of the pager.
> 
> * PoP (Action Pipeline) is a linear workflow to handle the request 
> cycle. It can do subcalls in the sense of PAC. It also is still 
> there, as the actions of bananas show. But the style has changed a 
> little.
> 
>> presented on the wiki 
>> http://wiki.typo3.org/index.php/MVC_Framework#The_Action_Pipeline
> 
> A while ago I already hinted, that I would strip the TS configurable 
> PoP from lib/div for some reasons and move it to an addon_extension.
> 
> 
> a) The pipeline requires knowlege about internal varible names of the
>  processor objects. Direct setter and getter methods for the 
> properties are missing. So the support by IDEs is low and people will
>  need some time to get used to this style.
> 
> b) XML templates, object trees and the TS tree are hierarchical 
> structures by nature. My longterm perspective is to make them work 
> together. To use them as different perspectives of the same tree 
> components. A linear pipeline is a helpful sideway for people used to
>  think in "batch mode" and worth to be offert as extension to
> lib/div. But it is not in the direct line towards matching XML, TS
> and objects structures.
> 
>> We had, previously, a clear file structure that looked like this :
>> 
>> - extension's root --- configurations/setup.txt --- controllers/** 
>> all my controllers ** --- models/** all my models ** --- views/** 
>> all my views **
>> 
>> Now, it seems that we have totaly reorganised the file 
>> organisation.
>> 
> 
> Well, a strict rule for file organisation is not required to use 
> lib/div. There are many good ways to organize the directories. It 
> depends on the targets of your project on which directory level you 
> want to separate model and view.
> 
>> If I understand well, bananas will be completed with 3 others 
>> folders which will present other programming coding style. (php4 - 
>> smarty - mvc)
> 
> Right. I use the different styles as top level of the directory 
> structure to underline that they show very different alternatives.
> 
>> Isn't it a weakness to multiplie the coding style's possibility ?
> 
> It's at least a weakness to give no recommendation at all, but  it's 
> also a weakness to have no competition. I think we can profit from 
> some competing styles in the beginning before we give a 
> recommendation. Else there is some risk that we recommend an inferior
>  style.
> 
> 
> 
> 
> 


Elmar Hinz a écrit :
> Hi Fabien,
> 
> thank you for reflecting the result of the developing process. On the
> first glance bananas will look very different again, but it isn't
> that much altered as it may seem.
> 
> Fabien Udriot wrote:
> 
>> Hi every one,
>> 
>> I did some testing with the subversion's lib and I feel quite
>> confused at the moment. It seems to me that we have droped the
>> concept of MVC.
> 
> As you see I scheduled an example plugin with strict MVC style in
> bananas. Lib/div itself is more finegrained than simple MVC. (Would
> you place the RTE transformations into model or view?)
> 
>> Furthermore, I don't see in bananas the PAC's concept any more
> 
> PAC and PoP is not the same but related:
> 
> * PAC (Hierarchical MVC) teaches, that there is a tree of nodes,
> where each node has all a model, a view and a controller. It's still
> there, for example in form of the pager.
> 
> * PoP (Action Pipeline) is a linear workflow to handle the request
> cycle. It can do subcalls in the sense of PAC. It also is still
> there, as the actions of bananas show. But the style has changed a
> little.
> 
>> presented on the wiki 
>> http://wiki.typo3.org/index.php/MVC_Framework#The_Action_Pipeline
> 
> A while ago I already hinted, that I would strip the TS configurable
> PoP from lib/div for some reasons and move it to an addon_extension.
> 
> 
> a) The pipeline requires knowlege about internal varible names of the
>  processor objects. Direct setter and getter methods for the
> properties are missing. So the support by IDEs is low and people will
> need some time to get used to this style.
> 
> b) XML templates, object trees and the TS tree are hierarchical
> structures by nature. My longterm perspective is to make them work
> together. To use them as different perspectives of the same tree
> components. A linear pipeline is a helpful sideway for people used to
> think in "batch mode" and worth to be offert as extension to lib/div.
> But it is not in the direct line towards matching XML, TS and objects
> structures.
> 
>> We had, previously, a clear file structure that looked like this :
>> 
>> - extension's root --- configurations/setup.txt --- controllers/**
>> all my controllers ** --- models/** all my models ** --- views/**
>> all my views **
>> 
>> Now, it seems that we have totaly reorganised the file
>> organisation.
>> 
> 
> Well, a strict rule for file organisation is not required to use
> lib/div. There are many good ways to organize the directories. It
> depends on the targets of your project on which directory level you
> want to separate model and view.
> 
>> If I understand well, bananas will be completed with 3 others
>> folders which will present other programming coding style. (php4 -
>> smarty - mvc)
> 
> Right. I use the different styles as top level of the directory
> structure to underline that they show very different alternatives.
> 
>> Isn't it a weakness to multiplie the coding style's possibility ?
> 
> It's at least a weakness to give no recommendation at all, but  it's
> also a weakness to have no competition. I think we can profit from
> some competing styles in the beginning before we give a
> recommendation. Else there is some risk that we recommend an inferior
> style.
> 
> 
> 
> 
>