Return-Path: X-Original-To: apmail-cocoon-users-archive@www.apache.org Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D5067E0FE for ; Mon, 18 Feb 2013 16:50:11 +0000 (UTC) Received: (qmail 95987 invoked by uid 500); 18 Feb 2013 16:50:11 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 95939 invoked by uid 500); 18 Feb 2013 16:50:11 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users@cocoon.apache.org List-Id: Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 95932 invoked by uid 99); 18 Feb 2013 16:50:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Feb 2013 16:50:11 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [77.240.19.7] (HELO whm06.louhi.net) (77.240.19.7) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Feb 2013 16:50:06 +0000 Received: from dsl-tkubrasgw1-50df65-154.dhcp.inet.fi ([80.223.101.154]:49522 helo=[127.0.0.1]) by whm06.louhi.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1U7TuS-001Gqh-JW for users@cocoon.apache.org; Mon, 18 Feb 2013 18:49:44 +0200 Message-ID: <51225BA6.4070500@digikartta.net> Date: Mon, 18 Feb 2013 18:49:42 +0200 From: Mika M Lehtonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: users@cocoon.apache.org Subject: Re: from Cforms to Wicket References: <511EA48B.3050400@digikartta.net> <512121CF.2040703@apache.org> <51212AC5.8090506@digikartta.net> <5121442C.5010307@digikartta.net> <5121EACE.1000300@apache.org> <51221A01.1030903@digikartta.net> <51221DC6.6010402@apache.org> <512221B4.6020601@digikartta.net> <512225F5.6010509@digikartta.net> <51223617.8050608@digikartta.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060601060807090308010004" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - whm06.louhi.net X-AntiAbuse: Original Domain - cocoon.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - digikartta.net X-Get-Message-Sender-Via: whm06.louhi.net: authenticated_id: mika@digikartta.net X-Virus-Checked: Checked by ClamAV on apache.org --------------060601060807090308010004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Yeah, I think so too. Thanks. - mika - 18.2.2013 18:44, Jos Snellings kirjoitti: > Nice overview! > > > On Mon, Feb 18, 2013 at 5:23 PM, gelo1234 > wrote: > > IMHO if you are dealing with XML data, there are only two valid > choices: XSLT or XQuery. > > Both can be used with Cocoon. XSLT is standard Cocoon supported > (by XSLTTransformer), > XQuery support for Cocoon exists in XQueryGenerator from eXistDB > (http://www.exist-db.org) > > Whin one to use ? :) I prefer XSLT, but you can choose the other > [1]. XSLT has the best support in Cocoon. > XSLT is much simpler in my opinion and it enables us to generate > ANY Content/Transformation with XML data. > XSLT is pretty well supported in most IDEs, be it Eclipse or NetBeans. > > Im not aware of any stack/framework that could be built on top of > XSLT (as a superset?). Actually XSLT is pretty much 4GL [2]. It is > declarative in its form so simple and yet with LEGO-like Cocoon > sitemaps approach best suited for very clean/RAD apps. > > I also suggest taking a diversed approach to development with > Cocoon. What I mean by diversed is that you don't necessarily have > to stick > to Cocoon tools only. In its 3.0 release Cocoon is considered to > be used across different development environments, even in its > simplest form > as a library for e.g. Java EE or Spring application. > Personally I prefer to use it as a mediation proxy with ESB-like > features and use the right tools/frameworks for your job. > For me it means: Java on server, Javascript/HTML on the client. > > Using Java on the client side in terms of Web app (as its with > Wicket) is IMHO very bad and ugly idea. > Other indirect uses of Java thats compiled into Javascript (like > GWT, Vaadin, Errai,....) is also kind of obscure and heavy-weight. > I dare to claim they will loose its share in future HTML5 development. > > Just use the right (and LIGHTWEIGHT ;) tool for your job :) > > Greetings, > Greg > > [1] www.w3.org/2006/Talks/0525-www2006-Kay.pdf > > [2] > http://en.wikipedia.org/wiki/Fourth-generation_programming_language > > > > 2013/2/18 Mika M Lehtonen > > > Yep, > but as I started this chain, I stated that my problem is to > "convert" my own defined dynamic XML into HTML4 (or HTML5) > forms. I was looking something to replace Cforms (not just > plain XSLT). I am also considering to move to C3 because as I > stated earlier, developing without tools is hard. If I could > take e.g. NetBeans and continue with that, I would be better > off in the long run. > > I was considering Apache Wickets because some integration has > been done with C3, but right now it doesn't seem to be a real > option. > > HTML5 is still hype from my point of view. > > > - mika - > > > 18.2.2013 15:50, gelo1234 kirjoitti: >> HTML5 in its basics is a superset of HTML4. If you don't use >> HTML5-specific tags/spec you go well with old good HTML4. >> >> The original issue was NOT whether to use HTML5 or old HTML, >> but whether to use CForms or just raw XHTML/HTML (4 or 5) forms. >> >> If you like to have HTML5 goodies in browsers that support >> it, just use e.g. Cocoon Actions in Sitemap OR Advanced >> Sitemap Matchers OR in REST-Controller by inspecting HTTP >> Headers return different Page that generate a different >> Content (with XSLT) for IE8. >> >> Greetings, >> -Greg >> >> >> 2013/2/18 Mika M Lehtonen > > >> >> Also HTML5 support for IE seems to be weak, even for IE9. >> There are still lot of people using IE8 or even older >> browser + lot of people in some sort of governmental >> offices using their own versions.. >> We can't sell apps without IE-support, absolutely no way. >> >> http://people.mozilla.com/~prouget/ie9/ >> >> >> - mika - >> >> >> 18.2.2013 14:45, Robby Pelssers kirjoitti: >> >> The only thing I wonder about is... >> >> Cocoon and neither XSLT2.0 support html5 >> serialization for all I know. So does someone using >> Cocoon already generate HTML5 content with Cocoon and >> how did you accomplish this. >> >> Cheers, >> Robby >> >> -----Original Message----- >> From: Mika M Lehtonen [mailto:mika@digikartta.net >> ] >> Sent: Monday, February 18, 2013 1:42 PM >> To: users@cocoon.apache.org >> >> Subject: Re: from Cforms to Wicket >> >> Ok, >> thanks for your efforts. HTML5 it is, with or without C3. >> >> - mika - >> >> >> 18.2.2013 14:25, Francesco Chicchiricc� kirjoitti: >> >> On 18/02/2013 13:09, Mika M Lehtonen wrote: >> >> Yeah, >> I know what you mean. Most of the Xforms >> sites are dated back to 2002 >> or 2003.. Sounds like a standard having >> glorious future behind.. >> >> This betterForm still sounded proper for my >> purposes because it >> actually implements server-side approache of >> Xforms. So I could use >> Xforms definition for producing HTML-forms, >> if I understood right. It >> actually resembles a lot of Cforms with a >> difference that it seems to >> be under development taking contemporary >> challenges into account. >> >> "under development" with latest release 4.1 >> dating 1 year back [1] >> >> But would I still need C3 (or C2.11 / C2.2)? >> >> It depends on you, and on how much effort do you >> want to put on this >> task. >> Anyway, not necessarily, even though Cocoon will >> help in you in the >> XML side if the job. >> >> I would like to get familiar with C3 if I >> only could figure out how >> to start. >> >> The biggest problem with C2.11, IMHO, was not >> having proper >> development tools to use. I ended up writing >> files with Notepad++. >> And I never realized how to do debugging.. >> >> [1] http://sourceforge.net/projects/betterform/files/ >> >> 18.2.2013 10:48, Francesco Chicchiricc� >> kirjoitti: >> >> On 17/02/2013 21:57, Mika M Lehtonen wrote: >> >> How about some XForms implementation >> like this >> http://www.betterform.de? >> Sounds promising.. >> >> I personally wouldn't bet much on XForms... >> >> Regards. >> >> >> --------------------------------------------------------------------- >> 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 >> >> >> > > > > > > -- > All generous minds have a horror of what are commonly called "Facts". > They are the brute beasts of the intellectual domain. > -- Thomas Hobbes --------------060601060807090308010004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Yeah,
I think so too. Thanks.

- mika -

18.2.2013 18:44, Jos Snellings kirjoitti:
Nice overview!


On Mon, Feb 18, 2013 at 5:23 PM, gelo1234 <gelo1234@gmail.com> wrote:
IMHO if you are dealing with XML data, there are only two valid choices: XSLT or XQuery.

Both can be used with Cocoon. XSLT is standard Cocoon supported (by XSLTTransformer),
XQuery support for Cocoon exists in XQueryGenerator from eXistDB (http://www.exist-db.org)

Whin one to use ? :) I prefer XSLT, but you can choose the other [1]. XSLT has the best support in Cocoon.
XSLT is much simpler in my opinion and it enables us to generate ANY Content/Transformation with XML data.
XSLT is pretty well supported in most IDEs, be it Eclipse or NetBeans.

Im not aware of any stack/framework that could be built on top of XSLT (as a superset?). Actually XSLT is pretty much 4GL [2]. It is declarative in its form so simple and yet with LEGO-like Cocoon sitemaps approach best suited for very clean/RAD apps.

I also suggest taking a diversed approach to development with Cocoon. What I mean by diversed is that you don't necessarily have to stick
to Cocoon tools only. In its 3.0 release Cocoon is considered to be used across different development environments, even in its simplest form
as a library for e.g. Java EE or Spring application.
Personally I prefer to use it as a mediation proxy with ESB-like features and use the right tools/frameworks for your job.
For me it means: Java on server, Javascript/HTML on the client.

Using Java on the client side in terms of Web app (as its with Wicket) is IMHO very bad and ugly idea.
Other indirect uses of Java thats compiled into Javascript (like GWT, Vaadin, Errai,....) is also kind of obscure and heavy-weight.
I dare to claim they will loose its share in future HTML5 development.

Just use the right (and LIGHTWEIGHT ;) tool for your job :)

Greetings,
Greg


2013/2/18 Mika M Lehtonen <mika@digikartta.net>
Yep,
but as I started this chain, I stated that my problem is to "convert" my own defined dynamic XML into HTML4 (or HTML5) forms. I was looking something to replace Cforms (not just plain XSLT). I am also considering to move to C3 because as I stated earlier, developing without tools is hard. If I could take e.g. NetBeans and continue with that, I would be better off in the long run.

I was considering Apache Wickets because some integration has been done with C3, but right now it doesn't seem to be a real option.

HTML5 is still hype from my point of view.


- mika -


18.2.2013 15:50, gelo1234 kirjoitti:
HTML5 in its basics is a superset of HTML4. If you don't use HTML5-specific tags/spec you go well with old good HTML4.

The original issue was NOT whether to use HTML5 or old HTML, but whether to use CForms or just raw XHTML/HTML (4 or 5) forms.

If you like to have HTML5 goodies in browsers that support it, just use e.g. Cocoon Actions in Sitemap OR Advanced Sitemap Matchers OR in REST-Controller by inspecting HTTP Headers return different Page that generate a different Content (with XSLT) for IE8.

Greetings,
-Greg


2013/2/18 Mika M Lehtonen <mika@digikartta.net>
Also HTML5 support for IE seems to be weak, even for IE9. There are still lot of people using IE8 or even older browser + lot of people in some sort of governmental offices using their own versions..
We can't sell apps without IE-support, absolutely no way.

http://people.mozilla.com/~prouget/ie9/

- mika -


18.2.2013 14:45, Robby Pelssers kirjoitti:

The only thing I wonder about is...

Cocoon and neither XSLT2.0 support html5 serialization for all I know.  So does someone using Cocoon already generate HTML5 content with Cocoon and how did you accomplish this.

Cheers,
Robby

-----Original Message-----
From: Mika M Lehtonen [mailto:mika@digikartta.net]
Sent: Monday, February 18, 2013 1:42 PM
To: users@cocoon.apache.org
Subject: Re: from Cforms to Wicket

Ok,
thanks for your efforts. HTML5 it is, with or without C3.

- mika -


18.2.2013 14:25, Francesco Chicchiriccò kirjoitti:
On 18/02/2013 13:09, Mika M Lehtonen wrote:
Yeah,
I know what you mean. Most of the Xforms sites are dated back to 2002
or 2003.. Sounds like a standard having glorious future behind..

This betterForm still sounded proper for my purposes because it
actually implements server-side approache of Xforms. So I could use
Xforms definition for producing HTML-forms, if I understood right. It
actually resembles a lot of Cforms with a difference that it seems to
be under development taking contemporary challenges into account.
"under development" with latest release 4.1 dating 1 year back [1]

But would I still need C3 (or C2.11 / C2.2)?
It depends on you, and on how much effort do you want to put on this
task.
Anyway, not necessarily, even though Cocoon will help in you in the
XML side if the job.

I would like to get familiar with C3 if I only could figure out how
to start.

The biggest problem with C2.11, IMHO, was not having proper
development tools to use. I ended up writing files with Notepad++.
And I never realized how to do debugging..
[1] http://sourceforge.net/projects/betterform/files/

18.2.2013 10:48, Francesco Chicchiriccò kirjoitti:
On 17/02/2013 21:57, Mika M Lehtonen wrote:
How about some XForms implementation like this
http://www.betterform.de?
Sounds promising..
I personally wouldn't bet much on XForms...

Regards.

---------------------------------------------------------------------
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







--
All generous minds have a horror of what are commonly called "Facts". They are the brute beasts of the intellectual domain.
-- Thomas Hobbes

--------------060601060807090308010004--