[TYPO3-ect] Spring and Symfony

[Steffen Kamper]

Hi,

"Daniel Pötzinger" <operation-lan at gmx.de> schrieb im Newsbeitrag 
news:mailman.1.1191757300.29224.typo3-team-extension-coordination at lists.netfielders.de...
> Elmar Hinz schrieb:
>> Hello,
>>
>> I compared lib to Spring (JAVA) and to Sympfony (PHP)
>>
>> Spring
>>
>> The core idea of Spring is, to configure singletons and there relations 
>> by a
>> configuration file. It is an implementation of the injection pattern. It
>> simplifies unit testing. Objects can be quickly exchanged by changing the
>> configuration file without the need to recompile at all.
>>
>> For JAVA objects that live persistantly in a container, it's a good idea 
>> to
>> instance them all in advance based on a configuration file. It's not 
>> useful
>> for an interpreted language like PHP. We only want to instance objects we
>> need on demand. To learn: Make all object relations configurable on the 
>> level of TS. Apart from this spring is a very flexible framework that can 
>> be combined
>> with other approches like XSLT, Struts, JSP etc. In this it is similar to
>> lib, wich also can combined with other libs on nearly every level.
>>
>> Symfony
>>
>> I mainly researched how the model is done, the DAO. It's Propel below. A
>> scaffold of the model is autogenerated based on an xml configuration 
>> file,
>> that describes the objects relations. The result is a model in 
>> traditional
>> style with a setter for each property: setId, setTitle, setName, .... 
>> After the quick startup by autogeneration the more work is awaiting 
>> because
>> of the setters. I think that's not really the road to go for lib/div,
>> taking your responses according this question into account. Different 
>> approaches are possible. We could use DAOs, that dynamically use
>> the TCA configuration instead of hardcoding all setters, wich is more
>> flexible than scaffolding.
>>
> +1
>
> In big projects I always have a seperate Folder called "dao", where Data 
> Access Objects are located. This is how I use them:
>
> have a class "dao_base" where all dao_* classes inherite from. The classes 
> are used to encapsulate all selects. So for each special purpose there is 
> a function which do some  selects - even more complex thing like doing 
> many selects..
> The classes are normaly used noninstanciated - like 
> dao_products::getSubItemsForCatagory($catid)
> or
> dao_products::deleteAttributesForProduct()
> ...
>
> But in terms of lib/div its better to use SingleTon for each DAO class.
>
> The advantages:
> 1) dao_base has standard functions like:
> - a "enableFields(table)" function (working for BE and FE)
> - quoteStr
> - where generators for wildcars searches ("austria* AND book")
> standard getRecord() and getRecords() functions
> example:
> http://typo3.org/extensions/repository/view/danp_libs/0.2.3/info/class.tx_danplibs_daobase.php/
>
>
> 2) DAO classes are reusable in FE and BE
>
> 3) Encapsulates all SQLs - e.g. you can exchange this classes dependend on 
> the database....
>
> 4) in terms of MVC they are normaly called only by the model
>
> 5) very easy to test with PHPUnit
>
>

following the DAO-way would go in other direction like the new devlist 
discussions about creating native db classes.
As ries is developing a t3lib_db for postgressql and oracle and Masi is 
looking for mysqli and stored sql  i think best would be to support them 
instead of doing it a different way.
Did you read the discussions?

vg  Steffen