Extensions and JS-frameworks

[Steffen Kamper-2]

Hi,

as all know JS-frameworks are not compatible and installing an extension
based on a JS-framework can destroy a page.

So i vote for a additional flag for extensions that use a framework, and
user know that before installing and testing. This flag should mention
the used framework

vg Steffen
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Martin Kutschker-7]

Steffen Kamper schrieb:
> Hi,
>
> as all know JS-frameworks are not compatible and installing an extension
> based on a JS-framework can destroy a page.
>
> So i vote for a additional flag for extensions that use a framework, and
> user know that before installing and testing. This flag should mention
> the used framework

If it's a flag it cannot carry additional data. The author could add
text data or some kind of framework key. But then we would need to
define the know frameworks. As the version might be of interest I would
require that every key carries a version number.

Masi
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Dmitry Dulepov [typo3]]

Hi!

Steffen Kamper wrote:
> as all know JS-frameworks are not compatible and installing an extension
> based on a JS-framework can destroy a page.
>
> So i vote for a additional flag for extensions that use a framework, and
> user know that before installing and testing. This flag should mention
> the used framework

What if extension can use several frameworks? I plan to modify ratings to enable mootools into addition to prototype.

--
Dmitry Dulepov
TYPO3 Core team
More about TYPO3: http://typo3bloke.net/
Subscribe: http://typo3bloke.net/rss.xml
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Steffen Kamper-2]

Martin Kutschker schrieb:

> Steffen Kamper schrieb:
>> Hi,
>>
>> as all know JS-frameworks are not compatible and installing an extension
>> based on a JS-framework can destroy a page.
>>
>> So i vote for a additional flag for extensions that use a framework, and
>> user know that before installing and testing. This flag should mention
>> the used framework
>
> If it's a flag it cannot carry additional data. The author could add
> text data or some kind of framework key. But then we would need to
> define the know frameworks. As the version might be of interest I would
> require that every key carries a version number.
>
> Masi

difficult - if it's a textfield the author could add any information about
If you want to bind it to version we need something like the
depending/suggesting-section

vg Steffen
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Steffen Kamper-2]

Hi,

Dmitry Dulepov [typo3] schrieb:

> Hi!
>
> Steffen Kamper wrote:
>> as all know JS-frameworks are not compatible and installing an
>> extension based on a JS-framework can destroy a page.
>>
>> So i vote for a additional flag for extensions that use a framework,
>> and user know that before installing and testing. This flag should
>> mention the used framework
>
> What if extension can use several frameworks? I plan to modify ratings
> to enable mootools into addition to prototype.
>

yes, that should be possible too if using a textfield
frameworks = prototype, mootools

It could be a section like the depending/suggesting-section
frameworks = array(
   'mootools' => '1.8',
   'prototype => '',
)

vg Steffen
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Michiel Roos [netcreators]]

Steffen Kamper schreef:
> It could be a section like the depending/suggesting-section
> frameworks = array(
>   'mootools' => '1.8',
>   'prototype => '',
> )
>

+1

--
Netcreators BV :: creation and innovation
www.netcreators.com

Interesse in werken bij Netcreators?
http://www.netcreators.com/bedrijf/vacatures/
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Ernesto Baschny [cron IT]]

Steffen Kamper wrote: on 13.07.2008 19:26:

> as all know JS-frameworks are not compatible and installing an extension
> based on a JS-framework can destroy a page.
>
> So i vote for a additional flag for extensions that use a framework, and
> user know that before installing and testing. This flag should mention
> the used framework

Can't the "frameworks" be provided as extensions and then we could use
the regular "depends" conditions in the ext_emconf.php?

For example there is t3mootools, extjs, etc.

There is also the "jsmanager" project from the ECT. Do you know the
status of that, is it "usable", is the approach ok?

Cheers,
Ernesto
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Steffen Kamper-2]

Ernesto Baschny [cron IT] schrieb:

> Steffen Kamper wrote: on 13.07.2008 19:26:
>
>> as all know JS-frameworks are not compatible and installing an
>> extension based on a JS-framework can destroy a page.
>>
>> So i vote for a additional flag for extensions that use a framework,
>> and user know that before installing and testing. This flag should
>> mention the used framework
>
> Can't the "frameworks" be provided as extensions and then we could use
> the regular "depends" conditions in the ext_emconf.php?
>
> For example there is t3mootools, extjs, etc.
>
> There is also the "jsmanager" project from the ECT. Do you know the
> status of that, is it "usable", is the approach ok?
>
> Cheers,
> Ernesto

Hi Ernesto,

i like to use them (eg for mootools this should go this way), but eg for
prototype it's not needed as it's shipped with core.
jsmanager isn't usable as it crashed on my 4.3dev (i think 4.2 also). I
didn't heard any news from Joerg a long time.
The approach is really a good one and should be pushed, i also think
that somethink like that should be provided from core for preventing
double-includes etc

vg Steffen

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

[Dmitry Dulepov [typo3]]

Hi!

Ernesto Baschny [cron IT] wrote:
> Can't the "frameworks" be provided as extensions and then we could use
> the regular "depends" conditions in the ext_emconf.php?
>
> For example there is t3mootools, extjs, etc.

A little problem with it is versioning of the frameworks. Some exts may depend on the specific version of the framework or require newer framework than exists in ext. I bumped into this with extjs: I want to use the extjs ext in my private extension but extjs ext did not have proper version in it.

--
Dmitry Dulepov
TYPO3 Core team
More about TYPO3: http://typo3bloke.net/
Subscribe: http://typo3bloke.net/rss.xml
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Steffen Kamper-2]

Dmitry Dulepov [typo3] schrieb:

> Hi!
>
> Ernesto Baschny [cron IT] wrote:
>> Can't the "frameworks" be provided as extensions and then we could use
>> the regular "depends" conditions in the ext_emconf.php?
>>
>> For example there is t3mootools, extjs, etc.
>
> A little problem with it is versioning of the frameworks. Some exts may
> depend on the specific version of the framework or require newer
> framework than exists in ext. I bumped into this with extjs: I want to
> use the extjs ext in my private extension but extjs ext did not have
> proper version in it.
>

give Joerg a mail - i think he will update the ext very soon.

vg Steffen
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Thorsten Kahler [dkd]]

Hi,

Dmitry Dulepov [typo3] schrieb:
> Ernesto Baschny [cron IT] wrote:
>> Can't the "frameworks" be provided as extensions and then we could use
>> the regular "depends" conditions in the ext_emconf.php?
>
> A little problem with it is versioning of the frameworks. Some exts may
> depend on the specific version of the framework or require newer
> framework than exists in ext. I bumped into this with extjs: I want to
> use the extjs ext in my private extension but extjs ext did not have
> proper version in it.

the "depends" logic also supports pointing to specific version ranges.
I'm not sure whether the extension manager does support that as well,
but that would be a different problem and not hard to manage.

So I support Ernestos suggestion:
- provide JS libraries solely as extensions in TER
- use the version of the library as extension version
- let these extensions provide two simple API calls to include the JS
lib in all (via ext_localconf.php) or distinct (module / plugin) BE or
FE pages.
- don't deliver JS libs with extensions, but use the "depends" mechanism
to have them at hand

Regards
Thorsten


--

Thorsten Kahler
thorsten.kahler@...
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Ernesto Baschny [cron IT]]

Thorsten Kahler [dkd] wrote: on 17.07.2008 09:30:

> Hi,
>
> Dmitry Dulepov [typo3] schrieb:
>> Ernesto Baschny [cron IT] wrote:
>>> Can't the "frameworks" be provided as extensions and then we could
>>> use the regular "depends" conditions in the ext_emconf.php?
>>
>> A little problem with it is versioning of the frameworks. Some exts
>> may depend on the specific version of the framework or require newer
>> framework than exists in ext. I bumped into this with extjs: I want to
>> use the extjs ext in my private extension but extjs ext did not have
>> proper version in it.
>
> the "depends" logic also supports pointing to specific version ranges.
> I'm not sure whether the extension manager does support that as well,
> but that would be a different problem and not hard to manage.
>
> So I support Ernestos suggestion:
> - provide JS libraries solely as extensions in TER
> - use the version of the library as extension version
> - let these extensions provide two simple API calls to include the JS
> lib in all (via ext_localconf.php) or distinct (module / plugin) BE or
> FE pages.
> - don't deliver JS libs with extensions, but use the "depends" mechanism
> to have them at hand

That would be cool. The only "problem" I see there is that the we then
depend on those ext-authors to update their JS-extensions. If they are
gone MIA, we have a problem. :)

So maybe we need to get those extensions in a broader community's hand,
in SVN and with at least 2-3 developers to update it from time to time.

Cheers,
Ernesto
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Steffen Kamper-2]

Ernesto Baschny [cron IT] schrieb:

> Thorsten Kahler [dkd] wrote: on 17.07.2008 09:30:
>> Hi,
>>
>> Dmitry Dulepov [typo3] schrieb:
>>> Ernesto Baschny [cron IT] wrote:
>>>> Can't the "frameworks" be provided as extensions and then we could
>>>> use the regular "depends" conditions in the ext_emconf.php?
>>>
>>> A little problem with it is versioning of the frameworks. Some exts
>>> may depend on the specific version of the framework or require newer
>>> framework than exists in ext. I bumped into this with extjs: I want
>>> to use the extjs ext in my private extension but extjs ext did not
>>> have proper version in it.
>>
>> the "depends" logic also supports pointing to specific version ranges.
>> I'm not sure whether the extension manager does support that as well,
>> but that would be a different problem and not hard to manage.
>>
>> So I support Ernestos suggestion:
>> - provide JS libraries solely as extensions in TER
>> - use the version of the library as extension version
>> - let these extensions provide two simple API calls to include the JS
>> lib in all (via ext_localconf.php) or distinct (module / plugin) BE or
>> FE pages.
>> - don't deliver JS libs with extensions, but use the "depends"
>> mechanism to have them at hand
>
> That would be cool. The only "problem" I see there is that the we then
> depend on those ext-authors to update their JS-extensions. If they are
> gone MIA, we have a problem. :)
>
> So maybe we need to get those extensions in a broader community's hand,
> in SVN and with at least 2-3 developers to update it from time to time.
>
> Cheers,
> Ernesto

good idea!

But what is with prototype? It's part of core so you don't need an
extension, but i need to know if an extension uses it.

vg Steffen
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Martin Kutschker-7]

Thorsten Kahler [dkd] schrieb:
> - use the version of the library as extension version

I don't think that this is clever:

* A library may have a different numbering scheme than the EM expects
for TYPO3 extensions .

* The extension might implement some kind of wrapper. Changes to that
glue code should be reflected in the extension own version.

So I think it makes more sense to change the EM config so that an
extension reports which 3rd party lib it includes and which version this
is is.

Alternatively we may demand that 3rd party libs are shipped always in
their own extension and *any* additional code has to be shipped in
another extension. But this also means eg that there has to one
Smarty/phpMyAdmin/AWstats extension without any TYPO3 glue. And another
one with addons on UI. This way you can separate the version of the lib
from the version of the intergratiion code.

Masi
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Thorsten Kahler [dkd]]

Martin Kutschker schrieb:
>> - use the version of the library as extension version
>
> I don't think that this is clever:
>
> * A library may have a different numbering scheme than the EM expects
> for TYPO3 extensions .

I thought about that, too. But unless there are any prominent/important
examples that don't fit to our scheme (or rather: can't be handled by
EM), this is theory. I don't expect this to be a real problem, because
TYPO3 uses the most common scheme <number>"."<number>"."<number>. A
quick search revealed a comparison table at Wikipedia [1]; maybe someone
wants to examine Ajaxian's list[2] as well.

>
> * The extension might implement some kind of wrapper. Changes to that
> glue code should be reflected in the extension own version.

Sorry, I don't exactly understand where your're pointing at.

>
> So I think it makes more sense to change the EM config so that an
> extension reports which 3rd party lib it includes and which version this
> is is.

Generally you're right: EM should distinguish between extensions and
external libraries. But that wouldn't ease the numbering problem either.

>
> Alternatively we may demand that 3rd party libs are shipped always in
> their own extension and *any* additional code has to be shipped in
> another extension. But this also means eg that there has to one
> Smarty/phpMyAdmin/AWstats extension without any TYPO3 glue. And another
> one with addons on UI. This way you can separate the version of the lib
> from the version of the intergratiion code.

Yes, that should be the result. And we'd need some kind of API (like
described for JS in my earlier post.


Regards
Thorsten

[1] <http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks>
[2] <http://ajaxian.com/resources>

--

Thorsten Kahler
thorsten.kahler@...
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

[Martin Kutschker-7]

Thorsten Kahler [dkd] schrieb:
>>
>> * The extension might implement some kind of wrapper. Changes to that
>> glue code should be reflected in the extension own version.
>
> Sorry, I don't exactly understand where your're pointing at.

I have no JS example, but let's take Smarty. Smarty has it's own
numbering. There are extensions that do more than contain the "raw"
Smarty code. They add some code to easy intergration from a TYPO3
extension (eg by using an extended base class instead of Smarty's base
class). They could (and do) add some extra stuff for tighter TYPO3
integration.

Now we have to version numbers: Smarty's and the TYPO3 extensions' (the
glue code).

Masi
_______________________________________________
TYPO3-dev mailing list
TYPO3-dev@...
http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev