My first impression of lib/div

[Benjamin Mack-4]

Hey guys,

I dug into lib / div the other day for the first time. I actually wanted
to use the set in my own extension.

As I looked at the source code for div, I was wondering why there are
functions duplicated from the core.

I mean, I usually call t3lib_div::makeInstance, now I need to call
tx_div::makeInstance and I don't see the reason why NOT to use the
classic t3lib_div ones (getGlobal etc etc). Same goes for some "key"
functions, which belong to the t3lib_extMgm class. Shouldn't we find
another way to have an extension for the stable releases 4x to merge
missing functions to the core?

Second of all, shouldn't we now force all developers to work with PHP5 ?
I mean, the admins (me included, I have two clients left with PHP4) now
need to upgrade to a new system, PHP4 is not supported anymore... so
let's get rid of it.

Third: Is the lib / div way the "official" way to making an extension to
TYPO3 5.0? I mean: Is it developed in discussion the v5 team or "just
another MVC framework" for TYPO3 ?

Forth: Is it finished? doesn't seem to be a lot of work going on there
anymore.

Thanks for all the answers.
benni.
-SDG-
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Benjamin Mack-4]

Hey guys,

I read about a templating implementation of using the "classic TYPO3
templating". I only seem to find the PHP templating -- how do I achieve
the TYPO3 one?

Sorry about the tone here, I'm just trying to understand the purposes
and the status, I don't want to attack somebody.

--
greetings,
benni.
-SDG-
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Daniel Bruessler-4]

Hello Benjamin,

use smarty for the templates, if you don't want to use the official
TYPO3 templates with ###MARKER###.

Cheers!
Daniel

> Hey guys,
>
> I read about a templating implementation of using the "classic TYPO3
> templating". I only seem to find the PHP templating -- how do I achieve
> the TYPO3 one?
>
> Sorry about the tone here, I'm just trying to understand the purposes
> and the status, I don't want to attack somebody.
>
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Daniel Bruessler-4]

Hello Benjamin,

the development of lib/div has stuck in alpha-state. The only support
you can get are the manuals in the wiki - e.g.
http://wiki.typo3.org/Apples and http://wiki.typo3.org/Bananas

The MVC-component of FLOW3 will be available for version 4 also, but not
yet.

So download the SVN-version of lib/div, and if you find problems then
correct it there. See http://wiki.typo3.org/Subversion

Cheers!
Daniel

> Hey guys,
>
> I dug into lib / div the other day for the first time. I actually wanted
> to use the set in my own extension.
>
> As I looked at the source code for div, I was wondering why there are
> functions duplicated from the core.
>
> I mean, I usually call t3lib_div::makeInstance, now I need to call
> tx_div::makeInstance and I don't see the reason why NOT to use the
> classic t3lib_div ones (getGlobal etc etc). Same goes for some "key"
> functions, which belong to the t3lib_extMgm class. Shouldn't we find
> another way to have an extension for the stable releases 4x to merge
> missing functions to the core?
>
> Second of all, shouldn't we now force all developers to work with PHP5 ?
> I mean, the admins (me included, I have two clients left with PHP4) now
> need to upgrade to a new system, PHP4 is not supported anymore... so
> let's get rid of it.
>
> Third: Is the lib / div way the "official" way to making an extension to
> TYPO3 5.0? I mean: Is it developed in discussion the v5 team or "just
> another MVC framework" for TYPO3 ?
>
> Forth: Is it finished? doesn't seem to be a lot of work going on there
> anymore.
>
> Thanks for all the answers.
> benni.
> -SDG-

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Hello Benjamin,

> I mean, I usually call t3lib_div::makeInstance, now I need to call
> tx_div::makeInstance and I don't see the reason why NOT to use the
> classic t3lib_div ones (getGlobal etc etc). Same goes for some "key"
> functions, which belong to the t3lib_extMgm class. Shouldn't we find
> another way to have an extension for the stable releases 4x to merge
> missing functions to the core?

No, this has been discussed before. It is unwanted to make changes in
the TYPO3 Core libraries. So all improvements and additions can only
come into the extensions lib/div.

- Franz

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Ingo Renner-2]

Franz Holzinger wrote:

Franz,

>> I mean, I usually call t3lib_div::makeInstance, now I need to call
>> tx_div::makeInstance and I don't see the reason why NOT to use the
>> classic t3lib_div ones (getGlobal etc etc). Same goes for some "key"
>> functions, which belong to the t3lib_extMgm class. Shouldn't we find
>> another way to have an extension for the stable releases 4x to merge
>> missing functions to the core?
>
> No, this has been discussed before. It is unwanted to make changes in
> the TYPO3 Core libraries. So all improvements and additions can only
> come into the extensions lib/div.

sorry, but this is plain non-sense and stupid! I can't believe you think
that way!


Ingo

--
Ingo Renner
TYPO3 Core Developer, Release Manager TYPO3 4.2
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Patrick Gaumond]

Ingo Renner wrote:

> sorry, but this is plain non-sense and stupid! I can't believe you think
> that way!

As Ries van Twisk would say: Popcorn !

Come on Ingo. Keep it non-personal.

Like it or not some people have tried (often the wrong way) to provide
code and suggestions and being turn down in a second.

What's left ?

Xclass, Hooks, lib/div and libraries.

For the last one check:
http://typo3.org/extensions/repository/?tx_terfe_pi1%5Bview%5D=search&no_cache=1&tx_terfe_pi1%5Bsword%5D=library

Personal attack brings you nowhere.

Patrick
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[omic]

> I mean, I usually call t3lib_div::makeInstance, now I need to call tx_div::makeInstance and I
> don't see the reason why NOT to use the classic t3lib_div ones (getGlobal etc etc). Same goes for
>  some "key" functions, which belong to the t3lib_extMgm class. Shouldn't we find another way to
> have an extension for the stable releases 4x to merge missing functions to the core?

The purpose of lib/div was to build a little framework that would enable the use of modern concept
like MVC, ORM, ... in TYPO3's extensions. A lot of work / activity has been done about this
mini-framework during the last year but sadly it didn't reach the "beta" status as desired.

Although some methods seem to be redundant, the idea (of Elmar ?) was to facilitate the migration
of an extension in V4 to V5. With only a few changes you would have a running extension in the next
version. (At least, it was desired...)

About this topic, does anybody has News from Elmar? Does he totally disappeared from TYPO3 ? No News
on his blog too.


> Second of all, shouldn't we now force all developers to work with PHP5 ? I mean, the admins (me
> included, I have two clients left with PHP4) now need to upgrade to a new system, PHP4 is not
> supported anymore... so let's get rid of it.

Long and hot discussions were hold on the mailing list last summer !!


 > Third: Is the lib / div way the "official" way to making an extension to TYPO3 5.0? I mean: Is it
 > developed in discussion the v5 team or "just another MVC framework" for TYPO3 ?

Well... difficult to advice to spend energy in this direction or not. A valuable reason would be, to
have already a clean MVC separation in your extension for V5. This definitely lacks in TYPO3.

But you must be aware that you will find most of the time examples as documentation. If you are
still interested, have a look at "ecorss".


kind regards,

Fabien

Patrick Gaumond a écrit :

> Ingo Renner wrote:
>
>> sorry, but this is plain non-sense and stupid! I can't believe you think that way!
>
> As Ries van Twisk would say: Popcorn !
>
> Come on Ingo. Keep it non-personal.
>
> Like it or not some people have tried (often the wrong way) to provide code and suggestions and
> being turn down in a second.
>
> What's left ?
>
> Xclass, Hooks, lib/div and libraries.
>
> For the last one check:
> http://typo3.org/extensions/repository/?tx_terfe_pi1%5Bview%5D=search&no_cache=1&tx_terfe_pi1%5Bsword%5D=library
>
>
>
>
> Personal attack brings you nowhere.
>
> Patrick

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Hello Benjamin,

> Forth: Is it finished? doesn't seem to be a lot of work going on there
> anymore.

The development is still in the starting phase. I am continuing with the
div2007 extension. Everybody is invited to contribute his library
functions in alpha state into div2007. These functions are collected
there until the ECT will rearrange them into a beta or stable function
for div.
The div2007 extension has been founded for compatibility reasons. The
function interface will change for all alpha functions. But you cannot
install many different versions of div at the same time. However
different extensions will base on different versions of div. So build
your extensions to not rely on div, but on div2007, div2008 ... div2100
in order not to have problems with changed API functions.

@ECT: Tell me when you think I should commit the div2007 functions also
to the div extension. It will be added to div in a few months, just
before the div2008 will come out.

- Franz
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Daniel Bruessler-4]

Hello Franz,

if we provide an upgrade-guide from one version to the next the problem
is solvable.

So it's no problem that just one version of lib and div can be on the
server. In the PEAR world it's easy to check WHAT version an installed
class has, but just ONE version of a package can be on the server. In
the Java world it's the same. A jar has a versionnumber, but when it's
in the classpath just one can be active.

=>
1. We need an upgrade-guide and so a fork "2007" and so on is not in need
2. The version-number of lib and div should be better:
<major>.<minor>.<bugfixes>

Until now just the bugfix-number was increased, but in reality the API
was changed all the time.

Wouldn't that solve the problems?

Cheers!
Daniel

>> Forth: Is it finished? doesn't seem to be a lot of work going on there
>> anymore.
> @ECT: Tell me when you think I should commit the div2007 functions also
> to the div extension. It will be added to div in a few months, just
> before the div2008 will come out.
> - Franz
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[philip.almeida]

Hello ECT,
Lib div is now alpha for to long, lib div is more then
a "duplication" of the core T3 API, it stands as a new
development paradigm for T3 developers opening the door and integrating
standard patterns like MVC, SPL, Registry.
I have developed 2 small
extensions based on it and I must say that the big outcome for me as a
developer was to have a well separate MVC model.
I did not master
the multi-controller feature of Lib/div or understand yet the full
benefict of switching controllers I admit I am still very
"green" on lib/div.
Either way  I would like to point the
following: 
1 - Regarding duplicating functions:
I see no
problem on it because lib/div is afterall a new api for TYPO3 framework
and stands as a independent API.
2 - New name div2008 etc...
I
do not like the concept of having div2007, div2008 and so on, it goes
against the unification of code it will be a mess on the long term. I
remember Elmar pointing that div2007 was a exception... (I subscribe
Daniel on this)
3 - Personaly I think Div should go beta even
against Elmar plan, the schedual is already broken and I see no one
following the original plan,
to long as alpha is bad and it have
given proof on field. Many people have already developed  some nice
extencions on it. Lib/div is nothing new is just a new way of putting
things but it is a step foward for new developers entering the Typo3
world.
 
Well I would like to help in the development of
Div as I putted to Elmar, I would like to work on the integration of
EXTJS, but I think we need a unified Div.
Best
regards, 
Philip Almeida 
 
> Hello Franz,
>
> if we provide an upgrade-guide from one version to the
next the problem
> is solvable.
>
> So it's
no problem that just one version of lib and div can be on the
>
server. In the PEAR world it's easy to check WHAT version an
installed
> class has, but just ONE version of a package can be on
the server. In
> the Java world it's the same. A jar has a
versionnumber, but when it's
> in the classpath just one can
be active.
>
> =>
> 1. We need an
upgrade-guide and so a fork "2007" and so on is not in need
> 2. The version-number of lib and div should be better:
>
<major>.<minor>.<bugfixes>
>
> Until
now just the bugfix-number was increased, but in reality the API
>
was changed all the time.
>
> Wouldn't that solve the
problems?
>
> Cheers!
> Daniel
>
>>> Forth: Is it finished? doesn't seem to be a lot of work
going on there
>>> anymore.
>> @ECT: Tell me when
you think I should commit the div2007 functions also
>> to the
div extension. It will be added to div in a few months, just
>>
before the div2008 will come out.
>> - Franz
>
_______________________________________________
>
TYPO3-team-extension-coordination mailing list
>
TYPO3-team-extension-coordination@...
>
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination
>
Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com/
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Hello Daniel,

> if we provide an upgrade-guide from one version to the next the problem
> is solvable.
>
> So it's no problem that just one version of lib and div can be on the
> server. In the PEAR world it's easy to check WHAT version an installed
> class has, but just ONE version of a package can be on the server. In
> the Java world it's the same. A jar has a versionnumber, but when it's
> in the classpath just one can be active.
>
> =>
> 1. We need an upgrade-guide and so a fork "2007" and so on is not in need
> 2. The version-number of lib and div should be better:
> <major>.<minor>.<bugfixes>
>
> Until now just the bugfix-number was increased, but in reality the API
> was changed all the time.
>
> Wouldn't that solve the problems?

No, this would not help very much. There will be several extensions
depending on different versions of div.
But you can only install one version of div at a time. And you want to
use all those extensions at the same time. All versions must be active
at the same time or you will have to wait until all those extensions are
available for the same version of div. And then there will be an update
of one of those extensions again using a changed API. So this is not
managable. The TYPO3 admin would have a lot of stress to get something
working.

- Franz



_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Daniel Bruessler-4]

Hello Franz,

so the only solutions seems to be that we use special extensionkeys for
every release of the framework.

* first release (=SVN branch01): lib 01 + div 01
* second release (=SVN branch02): lib 02 + div 02

Within a branch _NO change of the API_, just bugfix-updates.

And an alias for the current version: lib=lib02, div=div02 (we know this
from Linux. If you install "mysql" you get the latest version of mysql.

=> No problem to have several release-versions in the same installation.

Better?

Cheers!
Daniel

> (...) There will be several extensions
> depending on different versions of div.
> But you can only install one version of div at a time. And you want to
> use all those extensions at the same time. All versions must be active
> at the same time or you will have to wait until all those extensions are
> available for the same version of div. And then there will be an update
> of one of those extensions again using a changed API. So this is not
> managable. The TYPO3 admin would have a lot of stress to get something
> working.
>
> - Franz

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Hello Daniel

> so the only solutions seems to be that we use special extensionkeys for
> every release of the framework.

Yes, because the EM does not support 2 versions of an extension to be
installed at the same time. You cannot use div 0.0.12 and div 1.1.1
simultaneously.

> * first release (=SVN branch01): lib 01 + div 01
> * second release (=SVN branch02): lib 02 + div 02
>
> Within a branch _NO change of the API_, just bugfix-updates.

But additional functions and functionalities shall be allowed during
Alpha and Beta Phase. During beta phase only features from a defined
list may be commited.
Only bugfixes during RC phase.

> And an alias for the current version: lib=lib02, div=div02 (we know this
> from Linux. If you install "mysql" you get the latest version of mysql.

Yes, if you can accomplish this in the EM.
This would mean that you install div2007 and the function calls are
still div::functionname. The extension must define in ext_emconf.php
that it uses div2007 for div-calls. So you will need a nacro for this.

> => No problem to have several release-versions in the same installation.
>
> Better?
much better now


- Franz




_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Franz Holzinger a écrit :

>> so the only solutions seems to be that we use special extensionkeys for
>> every release of the framework.
>
> Yes, because the EM does not support 2 versions of an extension to be
> installed at the same time. You cannot use div 0.0.12 and div 1.1.1
> simultaneously.
>
>> * first release (=SVN branch01): lib 01 + div 01
>> * second release (=SVN branch02): lib 02 + div 02
>>
>> Within a branch _NO change of the API_, just bugfix-updates.
>

The best solution would only be to enhance the EM if nobody opposes.
Multiple versions of the same extension should be installable.
Each extension must tell in its ext_emconf.php for which version of an
extension it will work. This info must be updatable somewhere without a
necessary reupload of an extension.

The class name must contain a macro:

#define CLASSNAME_div  class.tx_div

class CLASSNAME_div {

}

If you call div::myfunction then this is not possible, because you can
only have one class with this name at a time.
This must be changed to the macro CLASSNAME_div::myfunction everywhere
in the code.

This is however untested and just a concept. Maybe something must be
changed here.

The macro can be undefined and redefined.

- Franz
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Benjamin Mack-4]

Hey all,

actually IMHO the best solution would be to integrate a stable version
of this API into the core (extension "cms"). Because ext devs already
have trouble to check which version of TYPO3 they are using
(compatversion is helping here), but with the whole lib / div versioning
mess it gets more complicated and ext devs would say "you can only use
my ext with div2007 and TYPO3 4.1" --- this is just plainly wrong. We're
trying to make it easier but actually we're making it more complicated.
div2007 was released because the div wasn't stable yet, and unless div
is not stable, it is not really useful IMHO.

Of course, people will complain that the development would be slower
when integrated in the core, but it does not make sense to change the
APIs of a MVC framework all the time (MVC isn't that complicated ;-)). A
framework is there to be stable, so the logical step would be to
finalize lib/div and then integrate it in 4.3.
The ext authors would only need to have a check if compatversion is 4.3
and otherwise would need to require lib / div from TER.

greetings,
benni.
-SDG

Daniel Bruessler wrote:

> Hello Franz,
>
> so the only solutions seems to be that we use special extensionkeys for
> every release of the framework.
>
> * first release (=SVN branch01): lib 01 + div 01
> * second release (=SVN branch02): lib 02 + div 02
>
> Within a branch _NO change of the API_, just bugfix-updates.
>
> And an alias for the current version: lib=lib02, div=div02 (we know this
> from Linux. If you install "mysql" you get the latest version of mysql.
>
> => No problem to have several release-versions in the same installation.
>
> Better?
>
> Cheers!
> Daniel

_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Daniel Bruessler-4]

Hello Franz,

>> so the only solutions seems to be that we use special extensionkeys for
>> every release of the framework.
>
> Yes, because the EM does not support 2 versions of an extension to be
> installed at the same time. You cannot use div 0.0.12 and div 1.1.1
> simultaneously.
>
>> * first release (=SVN branch01): lib 01 + div 01
>> * second release (=SVN branch02): lib 02 + div 02
>>
>> Within a branch _NO change of the API_, just bugfix-updates.
>
> But additional functions and functionalities shall be allowed during
> Alpha and Beta Phase. During beta phase only features from a defined
> list may be commited.
> Only bugfixes during RC phase.

An additional function _is_ an API-change :-)

Example: If lib02 and div03 are the current extensionkeys and they are
in use for some extensions any new functions should go into a new branch
lib03 and div03. Just bugfixes for already existing functions go in
lib02 and div02.

The alias: We can do it as "package extension". "lib" has the dependency
"lib02" and _NO code_ , same with "div".

Now ready?

>> Better?
> much better now
> - Franz
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Franz Holzinger]

Hello Daniel,

> Hello Franz,
>
>>> so the only solutions seems to be that we use special extensionkeys for
>>> every release of the framework.
>>
>> Yes, because the EM does not support 2 versions of an extension to be
>> installed at the same time. You cannot use div 0.0.12 and div 1.1.1
>> simultaneously.
>>
>>> * first release (=SVN branch01): lib 01 + div 01
>>> * second release (=SVN branch02): lib 02 + div 02
>>>
>>> Within a branch _NO change of the API_, just bugfix-updates.
>>
>> But additional functions and functionalities shall be allowed during
>> Alpha and Beta Phase. During beta phase only features from a defined
>> list may be commited.
>> Only bugfixes during RC phase.
>
> An additional function _is_ an API-change :-)
>
> Example: If lib02 and div03 are the current extensionkeys and they are
> in use for some extensions any new functions should go into a new branch
> lib03 and div03. Just bugfixes for already existing functions go in
> lib02 and div02.

This is bad. Imagine you are developing for div02 and then you want to
add a new function. Then this is so restrictive that you cannot continue
and must move to div03 which will take many months to get ready.
Or you must copy this code into all of your extensions. This is also bad.
This is only managable if div02 is already in RC phase. But it is too
restrictive during alpha and beta phase.

> The alias: We can do it as "package extension". "lib" has the dependency
> "lib02" and _NO code_ , same with "div".
>
Do you mean something like PHK?
http://www.phpindex.com/index.php/2006/12/17/2695-phk-un-gestionnaire-de-package-pour-php


Or maybe the PHP Package Management?

http://jacwright.com/blog/40/php-package-management-and-autoloading/


- Franz




_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[Daniel Bruessler-4]

Hello Franz,

>> An additional function _is_ an API-change :-)
>> Example: If lib02 and div03 are the current extensionkeys and they are
>> in use for some extensions any new functions should go into a new branch
>> lib03 and div03. Just bugfixes for already existing functions go in
>> lib02 and div02.

If you're the main-maintainer of div & lib it's easy for you to put
everything in the newest version of div & lib. You can always use the
current one in extensions like tt_products .

For others who want to use how it is (e.g. I'm one of this group) it's
good to have a defined version with a non-changing API. For example
"lib02" and "div02".

The alias: Please see the extension "ect". That is an
"extension-package". In our case we just have ONE extension in the package.

Clear now what I mean?

Cheers!
Daniel

> This is bad. Imagine you are developing for div02 and then you want to
> add a new function. Then this is so restrictive that you cannot continue
> and must move to div03 which will take many months to get ready.
> Or you must copy this code into all of your extensions. This is also bad.
> This is only managable if div02 is already in RC phase. But it is too
> restrictive during alpha and beta phase.
> - Franz
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination

[philip.almeida]

> Hello Franz,
>
>>> An additional function
_is_ an API-change :-)
>>> Example: If lib02 and div03 are
the current extensionkeys and they are
>>> in use for some
extensions any new functions should go into a new
>>>
branch
>>> lib03 and div03. Just bugfixes for already
existing functions go in
>>> lib02 and div02.
>
> If you're the main-maintainer of div & lib it's easy
for you to put
> everything in the newest version of div &
lib. You can always use the
> current one in extensions like
tt_products .
>
> For others who want to use how it is
(e.g. I'm one of this group) it's
> good to have a defined
version with a non-changing API. For example
> "lib02"
and "div02".
>
> The alias: Please see the
extension "ect". That is an
>
"extension-package". In our case we just have ONE extension in
the
> package.
>
> Clear now what I mean?
>
> Cheers!
>
Daniel
 
Hi,
Don't forget the KickStarter, the
grow of several div's can make the kickstarter development more
complicated.
This kind of evolution of the API (separated by Year)
is a new thing that you do not see elsewhere (as I Know).
I think
the step now should be the following:
1. See what must be done to
get to beta and close it.
2. After Beta consolidate documentation
and examples (which are already good) .
I would like to developed a
satellite like div__extjswidget but me and others need the confidence that
the API stays solid.
I am not going to develop
div2008__extjswidgets and etc, as well as different tutorials, it is hard
as is already.
Well this is my vision but I may be wrong.
Best
Regards,
Philip Almeida 
Einstein "Make things easy but
not easier, make  things simple but not simplier"
>
>> This is bad. Imagine you are developing for div02 and then
you want to
>> add a new function. Then this is so restrictive
that you cannot continue
>> and must move to div03 which will
take many months to get ready.
>> Or you must copy this code
into all of your extensions. This is also
>> bad.
>>
This is only managable if div02 is already in RC phase. But it is too
>> restrictive during alpha and beta phase.
>> -
Franz
> _______________________________________________
>
TYPO3-team-extension-coordination mailing list
>
TYPO3-team-extension-coordination@...
>
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination
>
Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com/
_______________________________________________
TYPO3-team-extension-coordination mailing list
TYPO3-team-extension-coordination@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination