click

›

click-user

Best practice for including js/css in Java

24 Messages

1 2

Ozakca, Muzaffer

Best practice for including js/css in Java

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Hi all,

What is a best practice for adding javascript or css files from within the Page java? I see there is a PageImports.java in the API but I’m not sure how to use it properly.

Thanks,

Muzaffer

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

sabob

Re: Best practice for including js/css in Java

Reply Threaded

Hi Muzaffer,

Do you want to insert external css/js files or internal scripts?

This is an area we are still working on at the moment but starting
with 1.5 you can do this:

public class MyPage extends Page {
public void onInit() {
...
}

public String getHtmlImports() {
return "<script type='text/javascript' src='path'></script>\n"
+ "<link type='text/css' href='path'/>";
}
}

Ozakca, Muzaffer wrote:

> Hi all,
>
>
>
> What is a best practice for adding javascript or css files from within
> the Page java? I see there is a PageImports.java in the API but I’m not
> sure how to use it properly.
>
>
>
> Thanks,
>
> Muzaffer
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click-user mailing list
> Click-user@...
> https://lists.sourceforge.net/lists/listinfo/click-user

Ozakca, Muzaffer

Re: Best practice for including js/css in Java

Reply Threaded

Bob, yes, internal script files, mostly. I was looking for something like getHtmlImports (I use that in my custom controls) because it's cleaner. I'm on 1.4 so I guess I'll use a public String for now. On another note, are you planning a more Javaish method of doing the same, similar to the way you're modified the listeners with 1.5? Not that I'm saying I need something like that, it just looks nicer to us purists :)

Thanks for the prompt reply btw,
Muzaffer

> -----Original Message-----
> From: click-user-bounces@... [mailto:click-user-
> bounces@...] On Behalf Of bob
> Sent: Wednesday, July 23, 2008 2:24 PM
> To: click-user
> Subject: Re: [Click-user] Best practice for including js/css in Java
>
> Hi Muzaffer,
>
> Do you want to insert external css/js files or internal scripts?
>
> This is an area we are still working on at the moment but starting
> with 1.5 you can do this:
>
> public class MyPage extends Page {
> public void onInit() {
> ...
> }
>
> public String getHtmlImports() {
> return "<script type='text/javascript' src='path'></script>\n"
> + "<link type='text/css' href='path'/>";
> }
> }
>
> Ozakca, Muzaffer wrote:
> > Hi all,
> >
> >
> >
> > What is a best practice for adding javascript or css files from within
> > the Page java? I see there is a PageImports.java in the API but I’m not
> > sure how to use it properly.
> >
> >
> >
> > Thanks,
> >
> > Muzaffer
> >
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Click-user mailing list
> > Click-user@...
> > https://lists.sourceforge.net/lists/listinfo/click-user
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Click-user mailing list
> Click-user@...
> https://lists.sourceforge.net/lists/listinfo/click-user

sabob

Re: Best practice for including js/css in Java

Reply Threaded

Ozakca, Muzaffer wrote:
> Bob, yes, internal script files, mostly. I was looking for something like getHtmlImports (I use that in my custom controls) because it's cleaner. I'm on 1.4 so I guess I'll use a public String for now. On another note, are you planning a more Javaish method of doing the same, similar to the way you're modified the listeners with 1.5? Not that I'm saying I need something like that, it just looks nicer to us purists :)

You mean Objects instead of Strings?

Prior to M2 there was an implementation which added 4 new controls:

CssImport, CssInclude, JavascriptImport, JavascriptInclude

Is this what you mean?

You can see an example of how its used here:
http://code.google.com/p/clickclick/source/browse/trunk/clickclick/jquery/src/net/sf/clickclick/jquery/controls/JQDialog.java

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

Ozakca, Muzaffer

Re: Best practice for including js/css in Java

Reply Threaded

Yes, similar to that idea so you were already addressing it. But if I were to design it, it would probably be 2 controls, e.g. PageInclude and PageImport, instead of 4.

Thanks!

> -----Original Message-----
> From: click-user-bounces@... [mailto:click-user-
> bounces@...] On Behalf Of bob
> Sent: Wednesday, July 23, 2008 3:22 PM
> To: click-user
> Subject: Re: [Click-user] Best practice for including js/css in Java
>
> Ozakca, Muzaffer wrote:
> > Bob, yes, internal script files, mostly. I was looking for something like
> getHtmlImports (I use that in my custom controls) because it's cleaner. I'm
> on 1.4 so I guess I'll use a public String for now. On another note, are you
> planning a more Javaish method of doing the same, similar to the way you're
> modified the listeners with 1.5? Not that I'm saying I need something like
> that, it just looks nicer to us purists :)
>
> You mean Objects instead of Strings?
>
> Prior to M2 there was an implementation which added 4 new controls:
>
> CssImport, CssInclude, JavascriptImport, JavascriptInclude
>
> Is this what you mean?
>
> You can see an example of how its used here:
> http://code.google.com/p/clickclick/source/browse/trunk/clickclick/jquery/sr
> c/net/sf/clickclick/jquery/controls/JQDialog.java
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Click-user mailing list
> Click-user@...
> https://lists.sourceforge.net/lists/listinfo/click-user

Les Hazlewood

Re: Best practice for including js/css in Java

Reply Threaded

Or you can have pageInclude just delegate its call to cssInclude and javascriptInclude calls, and similarly for pageImport. Then the user can choose which they want to override.

On Thu, Jul 24, 2008 at 9:31 AM, Ozakca, Muzaffer <mozakca@...> wrote:

Yes, similar to that idea so you were already addressing it. But if I were to design it, it would probably be 2 controls, e.g. PageInclude and PageImport, instead of 4.

Thanks!

> -----Original Message-----
> From: click-user-bounces@... [mailto:...
> bounces@...] On Behalf Of bob

> Sent: Wednesday, July 23, 2008 3:22 PM
> To: click-user
> Subject: Re: [Click-user] Best practice for including js/css in Java
>

> Ozakca, Muzaffer wrote:
> > Bob, yes, internal script files, mostly. I was looking for something like
> getHtmlImports (I use that in my custom controls) because it's cleaner. I'm
> on 1.4 so I guess I'll use a public String for now. On another note, are you
> planning a more Javaish method of doing the same, similar to the way you're
> modified the listeners with 1.5? Not that I'm saying I need something like
> that, it just looks nicer to us purists :)
>
> You mean Objects instead of Strings?
>
> Prior to M2 there was an implementation which added 4 new controls:
>
> CssImport, CssInclude, JavascriptImport, JavascriptInclude
>
> Is this what you mean?
>
> You can see an example of how its used here:
> http://code.google.com/p/clickclick/source/browse/trunk/clickclick/jquery/sr
> c/net/sf/clickclick/jquery/controls/JQDialog.java
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Click-user mailing list
> Click-user@...
> https://lists.sourceforge.net/lists/listinfo/click-user
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

sabob

Re: Best practice for including js/css in Java

Reply Threaded

In reply to this post by Ozakca, Muzaffer

Hi Muzaffer,

Ozakca, Muzaffer wrote:
> Yes, similar to that idea so you were already addressing it. But if I were to design it, it would probably be 2 controls, e.g. PageInclude and PageImport, instead of 4.

That can work too.

My thinking here was that the JS and CSS were conceptually different
enough to warrant their own class.

For example:
CSSImport would render: <link href=""/>
CSSInclude would render: <style type="...">...</style>
JavascriptInclude would render: <script type="...">...</script>

Having them in separate classes also ensures the API can grow without
interfering with each other. For example one can expose a method such
as JavascriptInclude#renderInsideComments which allows degrading on
old browsers, but commenting CSS might not make sense.

However this is still alpha stuff so comments are welcome :)

kind regards

bob

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

Toni Lamar

Re: Best practice for including js/css in Java

Reply Threaded

In reply to this post by Ozakca, Muzaffer

Ozakca, Muzaffer wrote:

Yes, similar to that idea so you were already addressing it. But if I were to design it, it would probably be 2 controls, e.g. PageInclude and PageImport, instead of 4.

I believe there's no need to have controls for that functionality, since those are not really "controls".

The Page API would be a better place for this.
1. Page#addImport(String path) -> if "path" ends with .css than in the background is added to the cssImports, and if "path" ends with .js than to the jsImports (or just to "imports", in no performance filter is used). The API could than transparently handle dupicates, performance filter/versions, append context, etc.

I believe that the above API would be much simpler to use and learn (even if *internally* - would work like the Controls moved to ClickClick).

Thnx,
Tom.

Les Hazlewood

Re: Best practice for including js/css in Java

Reply Threaded

I agree with the concept that Include/Import classes themselves aren't really 'controls'.

But shouldn't any control be able to contribute to the imports and includes of a page? This would allow control-specific JavaScript - very important.

The Page or Container objects should aggregate, or collect, all of the includes and imports of all of their children components and spit them out to the response. OO delegation and all that.

I'm somewhat new to the implementations of Click controls, but shouldn't they work like this?

On Thu, Jul 24, 2008 at 12:30 PM, Toni Lamar <toni.lamar@...> wrote:

Ozakca, Muzaffer wrote:
>
> Yes, similar to that idea so you were already addressing it. But if I were
> to design it, it would probably be 2 controls, e.g. PageInclude and
> PageImport, instead of 4.
>

I believe there's no need to have controls for that functionality, since
those are not really "controls".

The Page API would be a better place for this.
1. Page#addImport(String path) -> if "path" ends with .css than in the
background is added to the cssImports, and if "path" ends with .js than to
the jsImports (or just to "imports", in no performance filter is used). The
API could than transparently handle dupicates, performance filter/versions,
append context, etc.

I believe that the above API would be much simpler to use and learn (even if
*internally* - would work like the Controls moved to ClickClick).

Thnx,
Tom.
--
View this message in context: http://www.nabble.com/Best-practice-for-including-js-css-in-Java-tp18616874p18635625.html
Sent from the click-user mailing list archive at Nabble.com.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

sabob

Re: Best practice for including js/css in Java

Reply Threaded

Hi Les,

Les Hazlewood wrote:
> I agree with the concept that Include/Import classes themselves aren't
> really 'controls'.

Nods they are html elements rather than GUI controls. But Click does
not have an Element super class to extend from, so I jumped on the
Control infrastructure already provided by the framework. :)

> But shouldn't any control be able to contribute to the imports and
> includes of a page? This would allow control-specific JavaScript - very
> important.
>
> The Page or Container objects should aggregate, or collect, all of the
> includes and imports of all of their children components and spit them
> out to the response. OO delegation and all that.
>
> I'm somewhat new to the implementations of Click controls, but shouldn't
> they work like this?

Yep it does. Controls and Pages can contribute to the header by
overriding the method getHtmlImports and Click will ensure the imports
are unique.

However there are limitations in that an include or import must be
specified on a single line which is inconvenient.

kind regards

bob

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

Toni Lamar

Re: Best practice for including js/css in Java

Reply Threaded

sabob wrote:

> I agree with the concept that Include/Import classes themselves aren't
> really 'controls'.
Nods they are html elements rather than GUI controls. But Click does
not have an Element super class to extend from,

I don't believe there's a need for an Element super class - if Click would follow
the HTML for the API than it would look very ugly - for this there's already
Jakarta ECS:
http://jakarta.apache.org/ecs/index.html

I also believe, that in Click the users should think most of the time in terms of Pages and Controls (components - like it was in Delphi/VB)

sabob wrote:

so I jumped on the
Control infrastructure already provided by the framework. :)

I belive hacks are not a very good idea considering that Click keeps backwards compatibility for very important. After someting is "in" and released, is almost impossible to remove it, and such code just grows and grows :(.

sabob wrote:

However there are limitations in that an include or import must be
specified on a single line which is inconvenient.

This should not be a problem for imports if something like the following would be used:
Page (or Util) #addImport(String path)
Since the path would be "pure", e.g. "/assets/mystyle.css" (even without the context when added),
so always very fast to check for duplicates, versions (select packed/obfuscated version), etc.

For "includes" (mostly JS includes), I like to use most of the time the Velocity include:
#include("$context/assets/mySnippet.js)
This has the advantage that there's not need to escape in that snippet something, and the IDEs are
much smarter with "pure" JS files than with direct includes.

Thnx.
OT Delphi/VB: it seems that it is pretty simple to add in NetBeans to the pallette arbitrary controls (e.g. to work visually). I just started reading this one:
http://tinyurl.com/5px83y
and ch15 is all about this.

sabob

Re: Best practice for including js/css in Java

Reply Threaded

Toni Lamar wrote:

> I don't believe there's a need for an Element super class

Agreed :)

> This should not be a problem for imports if something like the following
> would be used:
> Page (or Util) #addImport(String path)
> Since the path would be "pure", e.g. "/assets/mystyle.css" (even without the
> context when added),
> so always very fast to check for duplicates, versions (select
> packed/obfuscated version), etc.
>
> For "includes" (mostly JS includes), I like to use most of the time the
> Velocity include:
> #include("$context/assets/mySnippet.js)

This won't work for custom Controls as they don't always have an
associated template.

Another issue I ran into was that includes could be checked for
uniqueness, especially for Controls. However Page includes won't have
to check for uniqueness as they are application specific. Using
objects instead of strings allows one to use methods on the Object to
set whether the include should be unique or not. Other advantages of
an Object is to add API for conditional includes, commented script
content etc.

> This has the advantage that there's not need to escape in that snippet
> something, and the IDEs are
> much smarter with "pure" JS files than with direct includes.

Yep I've been looking at JQuery Controls and placing the JS in their
own files is much easier to work.

> OT Delphi/VB: it seems that it is pretty simple to add in NetBeans to the
> pallette arbitrary controls (e.g. to work visually). I just started reading
> this one:
> http://tinyurl.com/5px83y
> and ch15 is all about this.

Nice. I use Netbeans myself and a Click Netbeans plugin would be very
welcome :)

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

Les Hazlewood

Re: Best practice for including js/css in Java

Reply Threaded

In reply to this post by Toni Lamar

On Thu, Jul 24, 2008 at 1:42 PM, Toni Lamar <toni.lamar@...> wrote:

sabob wrote:
>
>> I agree with the concept that Include/Import classes themselves aren't
>> really 'controls'.
> Nods they are html elements rather than GUI controls. But Click does
> not have an Element super class to extend from,
>

I don't believe there's a need for an Element super class - if Click would
follow
the HTML for the API than it would look very ugly - for this there's already
Jakarta ECS:
http://jakarta.apache.org/ecs/index.html

I agree - Click should not replicate HTML elements.

So, don't call it an Element. Create an interface called Component if that makes you feel better ;)

It makes sense to have a super interface when not everything is a Control, but behavior might be shared - nothing wrong with that. You can move these common methods up to Component and still have backwards compatibility.

What's wrong with that?

- Les

sabob

Re: Best practice for including js/css in Java

Reply Threaded

Les Hazlewood wrote:

> I agree - Click should not replicate HTML elements.
>
> So, don't call it an Element. Create an interface called Component if
> that makes you feel better ;)
>
> It makes sense to have a super interface when not everything is a
> Control, but behavior might be shared - nothing wrong with that. You
> can move these common methods up to Component and still have backwards
> compatibility.
>
> What's wrong with that?

Nothing wrong with that. But we should try to keep the abstractions to
a bare minimum. I do not think adding Component to support includes
and imports is worth the overhead at this stage.

Also I am coming around to the idea that the ClickClick Import and
Include classes should be utility classes instead of Controls.

regards

bob

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

Les Hazlewood

Re: Best practice for including js/css in Java

Reply Threaded

Well, if you think about a Container as well - that's not really a control, right? I mean, it is not something with which a user interacts directly. The user interacts with what it contains.

Same with a Form actually - it could be considered a Container as well. I guess that you click a submit button on a form might blur the lines a little bit, but the purists might say that the form is a Container and the submit button is a Control.

If you make this distinction, it kinda makes sense to have a parent Component interface.

I'm just thinking out loud :)

On Thu, Jul 24, 2008 at 2:36 PM, bob <sabob1@...> wrote:

Les Hazlewood wrote:
> I agree - Click should not replicate HTML elements.
>
> So, don't call it an Element. Create an interface called Component if
> that makes you feel better ;)
>
> It makes sense to have a super interface when not everything is a
> Control, but behavior might be shared - nothing wrong with that. You
> can move these common methods up to Component and still have backwards
> compatibility.
>
> What's wrong with that?

Nothing wrong with that. But we should try to keep the abstractions to
a bare minimum. I do not think adding Component to support includes
and imports is worth the overhead at this stage.

Also I am coming around to the idea that the ClickClick Import and
Include classes should be utility classes instead of Controls.

regards

bob

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Click-user mailing list
Click-user@...
https://lists.sourceforge.net/lists/listinfo/click-user

------------------------------------------------