You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by johnson <jo...@erp.tw> on 2007/06/17 04:25:04 UTC
About Client side Javascript in Cform
Hi!
Now In the Cform, There're lots of javascript in the client side, like
PopupWindow.js CFormsDragAndDropRepeater.js ....
I know there're different, but if we put it into one javascript file, the browser just only request one .js file, and the speed of cform will be faster.
is this idea correct?
Best Regards
johnson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: About Client side Javascript in Cform
Posted by Christian Schlichtherle <ch...@schlichtherle.de>.
Hi,
> Christian, I don't understand your proposal. What brings us
> using identity transformation?
it removes all whitespace as a side effect. Since you can easily add it to
any XSLT stylesheet, it works well.
Kind regards,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by Philippe Gauthier - INSERM SIRH <ph...@tolbiac.inserm.fr>.
Grzegorz Kossakowski a écrit :
> Christian Schlichtherle pisze:
>> Hi,
>>
>>> I have been thinking about similar functionality you describe. For a
>>> sign that it makes sense I suggest to take a look at Dojo's ShrinkSafe
>>> tool: http://dojotoolkit.org/docs/shrinksafe
>>
>> it may be one of the best kept public secrets of XSLT, but a simple
>> identity
>> transformation will do this, too. Since XSLT is ubiquitiously used
>> within
>> Cocoon, there's plenty of options to integrate the identity
>> transformation
>> in other transformations without adding another transformation step
>> into a
>> pipeline. So I don't think an additional solution would be required.
>> I think
>> the real missing link is an example in the documentation.
>>
>> Here's how a complete script would look like:
>>
>> <xsl:stylesheet version="1.0"
>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>> <!-- Identity transformation. -->
>> <xsl:template match="@*|node()">
>> <xsl:copy>
>> <xsl:apply-templates select="@*|node()"/>
>> </xsl:copy>
>> </xsl:template>
>> </xsl:stylesheet>
>
> Christian, I don't understand your proposal. What brings us using
> identity transformation?
>
Hi,
It would join all lines of the input javascript as xml.
--
Philippe Gauthier
INSERM
DRH - SIRH
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Christian Schlichtherle pisze:
> Hi,
>
>> I have been thinking about similar functionality you
>> describe. For a sign that it makes sense I suggest to take a
>> look at Dojo's ShrinkSafe
>> tool: http://dojotoolkit.org/docs/shrinksafe
>
> it may be one of the best kept public secrets of XSLT, but a simple identity
> transformation will do this, too. Since XSLT is ubiquitiously used within
> Cocoon, there's plenty of options to integrate the identity transformation
> in other transformations without adding another transformation step into a
> pipeline. So I don't think an additional solution would be required. I think
> the real missing link is an example in the documentation.
>
> Here's how a complete script would look like:
>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <!-- Identity transformation. -->
> <xsl:template match="@*|node()">
> <xsl:copy>
> <xsl:apply-templates select="@*|node()"/>
> </xsl:copy>
> </xsl:template>
> </xsl:stylesheet>
Christian, I don't understand your proposal. What brings us using identity transformation?
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: About Client side Javascript in Cform
Posted by Christian Schlichtherle <ch...@schlichtherle.de>.
Hi,
> I have been thinking about similar functionality you
> describe. For a sign that it makes sense I suggest to take a
> look at Dojo's ShrinkSafe
> tool: http://dojotoolkit.org/docs/shrinksafe
it may be one of the best kept public secrets of XSLT, but a simple identity
transformation will do this, too. Since XSLT is ubiquitiously used within
Cocoon, there's plenty of options to integrate the identity transformation
in other transformations without adding another transformation step into a
pipeline. So I don't think an additional solution would be required. I think
the real missing link is an example in the documentation.
Here's how a complete script would look like:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!-- Identity transformation. -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
Kind regards,
Christian
Re: About Client side Javascript in Cform
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> On 19.06.2007 10:12, Tobia wrote:
>
>> In fact I've noticed that the number of client-side javascript files
>> (not their complexity or size, so much as their number) referenced to by
>> Cocoon forms has a considerable impact on page load time.
>
> But if set up correctly with the appropriate response headers this
> should only happen on the first access. Afterwards the files should be
> taken from the browser's cache. Actually they can be cached quite
> aggressively.
Yes, but it's quite annoying that this first access takes so long. It may make potential user go away, especially when browser freezes.
> And that's the point where all the optimizations can even be
> counterproductive. Collecting the parts you actually need for the page
> and merging them makes them individual for that page (or a group of
> pages) and the files need to be retrieved for every actual combination
> of them.
>
> If size and whitespace matter why not just gzipping them?
Yes, it's another, valid, point of view. Meanwhile, we could think about making this behaviour (aggressive caching + gzipping) default.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.06.2007 10:12, Tobia wrote:
> In fact I've noticed that the number of client-side javascript files
> (not their complexity or size, so much as their number) referenced to by
> Cocoon forms has a considerable impact on page load time.
But if set up correctly with the appropriate response headers this
should only happen on the first access. Afterwards the files should be
taken from the browser's cache. Actually they can be cached quite
aggressively.
And that's the point where all the optimizations can even be
counterproductive. Collecting the parts you actually need for the page
and merging them makes them individual for that page (or a group of
pages) and the files need to be retrieved for every actual combination
of them.
If size and whitespace matter why not just gzipping them?
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by Tobia <to...@linux.it>.
Grzegorz Kossakowski wrote:
> I was thinking about some _transformer_ that seeks HTML stream in
> order to gather all <script src=".."/> occurrences and replaces it
> with one looking like this: <script src="cocoon-assembly-
> [radnom_characters_here].js"/> and "magically" creates this assembly
> file consisting of all files referenced by HTML stream.
>
> Thoughts? Do you think that such functionality would be worth the
> effort?
I think so and I would certainly use it.
In fact I've noticed that the number of client-side javascript files
(not their complexity or size, so much as their number) referenced to by
Cocoon forms has a considerable impact on page load time.
I'm sure compressing the scripts with one of the free javascript
compressors and joining them into a single assembly file would speed up
page loading a lot.
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Jason Johnston pisze:
>
> (At the risk of adding more confusion regarding our names... ;-) )
;-)
> Yes! I'll give it a shot. I actually implemented a similar Reader a
> while back based on Dean Edwards' Packer [1]. I'll see how ShrinkSafe
> compares and see about getting one or the other committed. Where would
> be the best place for it? Core? AJAX block?
Are you going to provide it for Cocoon 2.2? I guess it's only sensible option because 2.1.x will switch to maintence
mode really soon.
I was thinking about some _transformer_ that seeks HTML stream in order to gather all <script src=".."/> occurrences and
replaces it with one looking like this:
<script src="cocoon-assembly-[radnom_characters_here].js"/>
and "magically" creates this assembly file consisting of all files referenced by HTML stream. It would work for Dojo
because we could try to integrate Dojo's build system:
http://dojotoolkit.org/book/dojo-book-0-4/part-6-customizing-dojo-builds-better-performance/dojo-build-system/creating-cust
I'm not sure how much effort is needed in order to achieve Cocoon producing Dojo's distribution on-the-fly but it would
be even more great than just integrating ShrinkSafe.
Thoughts? Do you think that such functionality would be worth the effort?
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by Jason Johnston <co...@lojjic.net>.
Grzegorz Kossakowski wrote:
> Dev at weitling pisze:
>> Hi Johnson senior,
>>
>>> This is Johnson, Jason is my son :-D
>>>
>> Seems I'm becoming old... missed a 't' and made a wrong guess :-)
>>
>>> I'm suffering with CDMA(3G) connection :'(
>>>
>> Well, then let's see what we can do: We need a Generator that
>> simply converts Javascript to XML by exchanging "<" and friends
>> with "<" and wrap it in "script type="text/javascript"></script>
>> Then exchange those <script src="some.js"/> with
>> XInclude/CInclude, either manually or with XSL.
>>
>> This is not ironic: What about a kind of transformer/serializer
>> filtering double spaces and CR/LF?
>
> Johnson, Florian, don't be shy with your proposals. ;-)
>
> I have been thinking about similar functionality you describe. For a
> sign that it makes sense I suggest to take a look at Dojo's
> ShrinkSafe tool: http://dojotoolkit.org/docs/shrinksafe
>
> I think that integration of ShrinkSafe with Cocoon would be awesome.
> Anyone interested in implementing it?
(At the risk of adding more confusion regarding our names... ;-) )
Yes! I'll give it a shot. I actually implemented a similar Reader a
while back based on Dean Edwards' Packer [1]. I'll see how ShrinkSafe
compares and see about getting one or the other committed. Where would
be the best place for it? Core? AJAX block?
--Jason
http://dean.edwards.name/packer/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Dev at weitling pisze:
> Hi Johnson senior,
>
>> This is Johnson, Jason is my son :-D
>>
>
> Seems I'm becoming old... missed a 't' and made a wrong guess :-)
>
>> I'm suffering with CDMA(3G) connection :'(
>>
>
> Well, then let's see what we can do:
> We need a Generator that simply converts Javascript to XML by exchanging
> "<" and friends with "<" and wrap it in "script
> type="text/javascript"></script>
> Then exchange those <script src="some.js"/> with XInclude/CInclude,
> either manually or with XSL.
>
> This is not ironic: What about a kind of transformer/serializer
> filtering double spaces and CR/LF?
Johnson, Florian, don't be shy with your proposals. ;-)
I have been thinking about similar functionality you describe. For a sign that it makes sense I suggest to take a look at Dojo's ShrinkSafe
tool: http://dojotoolkit.org/docs/shrinksafe
I think that integration of ShrinkSafe with Cocoon would be awesome. Anyone interested in implementing it?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by Dev at weitling <de...@weitling.net>.
Hi Johnson senior,
> This is Johnson, Jason is my son :-D
>
Seems I'm becoming old... missed a 't' and made a wrong guess :-)
> I'm suffering with CDMA(3G) connection :'(
>
Well, then let's see what we can do:
We need a Generator that simply converts Javascript to XML by exchanging
"<" and friends with "<" and wrap it in "script
type="text/javascript"></script>
Then exchange those <script src="some.js"/> with XInclude/CInclude,
either manually or with XSL.
This is not ironic: What about a kind of transformer/serializer
filtering double spaces and CR/LF?
Bye,
Florian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by johnson <jo...@erp.tw>.
Hi!
This is Johnson, Jason is my son :-D
I'm suffering with CDMA(3G) connection :'(
Johnson
Dev at weitling 提到:
> Hi Jason,
>
> yes, speed would increase.
> But: Maintainability would decrease.
> And: Do you know anyone still surfing with a 14.4K modem?
>
> I prefer investing my energy into universal peace :-)
>
> BTW: It's sunday!
>
> Florian
>
>
>
> johnson wrote:
>
>> Hi!
>>
>> Now In the Cform, There're lots of javascript in the client side, like
>>
>> PopupWindow.js CFormsDragAndDropRepeater.js ....
>>
>> I know there're different, but if we put it into one javascript file, the browser just only request one .js file, and the speed of cform will be faster.
>>
>> is this idea correct?
>>
>> Best Regards
>>
>> johnson
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: About Client side Javascript in Cform
Posted by Dev at weitling <de...@weitling.net>.
Hi Jason,
yes, speed would increase.
But: Maintainability would decrease.
And: Do you know anyone still surfing with a 14.4K modem?
I prefer investing my energy into universal peace :-)
BTW: It's sunday!
Florian
johnson wrote:
> Hi!
>
> Now In the Cform, There're lots of javascript in the client side, like
>
> PopupWindow.js CFormsDragAndDropRepeater.js ....
>
> I know there're different, but if we put it into one javascript file, the browser just only request one .js file, and the speed of cform will be faster.
>
> is this idea correct?
>
> Best Regards
>
> johnson
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org