[TYPO3-dev] Your opinion please: ZF and T3

[Christian Opitz - Netzelf]

Hi Dmitry,

thanx for your answer :)

The extension ZFext is now the very last extension in forge.typo3.org :)
http://forge.typo3.org/projects/show/extension-zfext

If you want, you can check it out - it should work.

>> Actually the typoscript generated by Zfext_ExtMgm::addPItoST43() is the
>> same as that of the method in t3lib_extMgm. Except three differences.
>> Code says it faster than words:
>>
>> plugin.tx_zfextexample_pi1 = USER_INT
>> plugin.tx_zfextexample_pi1 {
>>      includeLibs = typo3conf/ext/zfext/plugin/class.tx_zfext.php
>>      userFunc = tx_zfext->main
>>      prefixId = tx_zfextexample_pi1
>> }
>>
>> I can live with the includeLibs and userFunc property but the prefixId
>> bothers me somehow (BUT i need it in the zfext-plugin to resolve which
>> plugin was called).
>>      
> Don't call it "prefixId" :) Choose a better name and that's it. What about
> "handlerClass" or something like that?
>
>    
I thought about calling it signature and put the extkey in it too: 
(signature = zfext_example.tx_zfextexample_pi1)
>> Second thing that worries me is if i should support more types than the
>> list_type - currently i do. Does anybody want to put that kind of plugin
>> in another than the list_type?
>>      
> If you have more flexibility – it is good. For example, I crated several
> extra types (that "scary" kickstarter option). It is often good.
>
>    
so i think, i rather keep it.
>> And just to be complete, I'd like to ask you another last thing: The
>> prefixId in the plugin-conf is the key to an entry in
>> config.tx_zfext.resources.zfext where per default only the extKey is
>> set. When you change the default options defined as static variable in
>> Zfext_ExtMgm (actually defaultController, defaultAction, autoload,
>> suffixInClassName and namespace) these will be found in this object too
>> (Set by Zfext_ExtMgm::addPItoST43). So for instance when you register
>> the above plugin like that:
>>
>> Zfext_ExtMgm::addPItoST43($_EXTKEY, array(
>>      'directory' =>  'pi1',
>>      'suffix' =>  '_pi1',
>>      'cached' =>  false,
>>      'suffixInClassName' =>  false
>> ));
>>      
> Why do you use "addPItoST43"? You are doing a new thing, so why do you have
> to use those old cryptic names? Can't you give it a good speaking name? Do
> it right from the beginning or it will never be good :)
>    
Because i actually did not want to write something very new but rather 
combine two already good things. With that i aimed to say developers 
that this function does the same like that in t3lib. But i could move 
that to the docBlock too and call it registerPlugin (addPlugin could 
probably be misleading, because theres already on in t3lib_extMgm for 
ext_tables).
>> Do you like that way - or would you prefer to have the configuration for
>> each plugin directly in it's USER-object? (I thought that this could
>> sometimes lead to problems and misunderstandings)
>>      
> I think TS is better. In general having just one way is better.
>    
Oh - i meant TS - but which key there plugin.tx_example or 
config.tx_zfext.resources.zfext.tx_example?
>    
>> P.S.:
>> In the example above standard controller class will be in
>> EXT:zfext_example/pi1/controllers/IndexController.php and must be named
>> Tx_ZfextExample_IndexController (Same pattern for models, forms etc.)
>> The complete TS-config for zfext in my current test-installation is that:
>>      
> You use syntax for Extbase (Tx_ with upper case "T") but your file sytem
> structure seems to be old. That's not consistent. Either use new file
> system structure or old naming, don't mix both.
>
> In general, if you do something new, do it right from the beginning, try
> not to reuse old bad names or principles.
>    
"My" convention is that the same structure like in ZF-modules is used 
and that the prefixId in upper camel case is used as class name prefix. 
I don't want to restrict developers to make a pi1 folder or something 
like that. The pi1-folder is just for the example and with it i aimed to 
show the integrity of ZFext. Generally your free to even put your 
controllers/models/views etc. directly in your extension root or in some 
deeper nested directory.
>    
>> config {
>>      tx_zfext {
>>      
> Is there any technical reason to use "config"? That array is loaded early
> at each page. If you add a lot of info there, you increase memory
> requirements for each request.
>
>    
This setup is completely passed as bootstrap config to Zend_Application. 
ZFext is currently registering its plugin and library with 
Zfext_ExtMgm::addPItoST43 and Zfext_Mgm::addLibrary itself - that's why 
i did not put this setup in plugin.tx_zfext. Besides i saw it in extbase 
and thought "Ok - they do it like that, i'll do that too". But i could 
move it to plugin.tx_zfext again.