Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #22671 > unrolled thread

Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc...

Back to article view | Back to comp.lang.java.programmer

Contents

  Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-01 22:34 -0400
    Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Joerg Meier <joergmmeier@arcor.de> - 2013-03-02 04:00 +0100
    Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-02 00:13 -0400
    Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-03-01 22:11 -0800
      Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-03-02 08:57 +0000
        Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-03 21:48 -0500
          Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-03-04 08:29 +0000
      Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-02 09:58 -0400
      Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Fredrik Jonson <fredrik@jonson.org> - 2013-03-02 14:46 +0000
        Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... markspace <markspace@nospam.nospam> - 2013-03-02 07:11 -0800
        Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-03 21:55 -0500
        Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Roedy Green <see_website@mindprod.com.invalid> - 2013-03-06 09:07 -0800
          Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-06 20:13 -0500
      Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-03 21:47 -0500
        Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... David Lamb <dalamb@cs.queensu.ca> - 2013-03-03 21:57 -0500
          Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-03 22:08 -0500
          Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-03 23:11 -0400
            Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-06 20:15 -0500
              Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-07 05:08 -0400
                Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-07 11:42 -0500
    Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-03 21:45 -0500
      Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-04 05:53 -0400
        Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-06 20:10 -0500
          Writing ones one Annotation processor (was: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc...) Joerg Meier <joergmmeier@arcor.de> - 2013-03-07 02:17 +0100
            Re: Writing ones one Annotation processor Arne Vajhøj <arne@vajhoej.dk> - 2013-03-06 20:36 -0500
          Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-07 06:39 -0400
            Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-07 11:41 -0500
              Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-07 20:28 -0400
                Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-07 21:24 -0500
                  Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-08 05:49 -0400
                    Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-03-08 12:20 +0000
                    Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Leif Roar Moldskred <leifm@dimnakorr.com> - 2013-03-08 12:06 -0600
                      Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-08 20:44 -0400
                        Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-11 18:07 -0400
                          Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Joerg Meier <joergmmeier@arcor.de> - 2013-03-11 23:27 +0100
                            Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-11 18:33 -0400
                          Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-11 21:12 -0300
                            Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-11 20:24 -0400
                              Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-03-11 21:38 -0300
                                Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-11 20:58 -0400
                              Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Robert Klemme <shortcutter@googlemail.com> - 2013-03-13 08:04 +0100
                      Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-11 17:57 -0400
                        Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Lew <lewbloch@gmail.com> - 2013-03-11 16:46 -0700
                          Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-11 20:27 -0400
                    Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc... Arne Vajhøj <arne@vajhoej.dk> - 2013-03-11 17:54 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#22700

On 3/1/2013 9:34 PM, Arved Sandstrom wrote:
> I just had an epiphany today at work. For years upon years I have used
> Java libraries which have grown increasingly cumbersome and finicky and
> unreliable to do XML or JSON in a REST context...99 percent of which is
> actually super-simple.
>
> The epiphany came when neither Jettison (the default Jersey JSON
> library) nor Jackson (which is undoubtedly more modern) could, out of
> the box without arcane configuration tweaks, convert a single-item list
> into a JSON array. They both just converted the item into a JSON object
> and forgot about the array.
>
> Apparently this catches out a lot of people, judging by googling. The
> Jackson solutions are many. The point being - leading to my epiphany -
> why the hell is this even a problem?
>
> I have probably wasted tens of weeks on the arcana of Jersey, Jackson,
> XStream to some extent, JAXB...I'm ditching most all of it. It is an
> obstacle.
>
> XStream I actually like for producing and consuming XML. It works
> nicely. I'll keep it in the toolbox. But for almost everything I do with
> Java REST, there is no call for Jersey (nor Jackson et al. for JSON
> (de-)serialization). It's a bunch of extra JARs for no added value.
>
> It occurred to me that for over 90 percent of my POJOs I can write
> reliable toJSON() methods that *will not break* and are fully under my
> control in a matter of minutes. For anything more I might give
> simple-json a whirl - it actually has appealing simplicity.
>
> And Jersey has got to go. Why do we even drink that Kool-Aid? Once
> you've got your JSON string a handful of lines of code with an HTTP
> client will take care of your REST call. A lot more reliable.

I think we need to split the stuff in 3 parts:
A) server side framework to enable declarative JAX-RS to work in a
    servlet container
B) the JSON/POX serializer
C) client side framework

re A)

I don't hear you argue against that. And I don't recall much
criticism from other either.

re B)

You don't like the common libraries. I know several people that
don't like them either (I don't have so much personal experience).

But is it really the concept that is wrong or is it just the
implementations?

My guess is still the implementations. I am not too keen on
toJSON, toXML, toJSONAlternative, toXMLALternative etc.etc.
on all DTO's.

We may not always like SOAP and all the associated standards,
but sometimes the "there is only one right way" philosophy
do make life easier.

re C)

I think it is rather common to use plain HttpClient.

Non-Java client to Java service is probably also a very
common combination.

Arne

[toc] | [prev] | [next] | [standalone]

#22710

On 03/03/2013 10:45 PM, Arne Vajhøj wrote:
> On 3/1/2013 9:34 PM, Arved Sandstrom wrote:
>> I just had an epiphany today at work. For years upon years I have used
>> Java libraries which have grown increasingly cumbersome and finicky and
>> unreliable to do XML or JSON in a REST context...99 percent of which is
>> actually super-simple.
>>
>> The epiphany came when neither Jettison (the default Jersey JSON
>> library) nor Jackson (which is undoubtedly more modern) could, out of
>> the box without arcane configuration tweaks, convert a single-item list
>> into a JSON array. They both just converted the item into a JSON object
>> and forgot about the array.
>>
>> Apparently this catches out a lot of people, judging by googling. The
>> Jackson solutions are many. The point being - leading to my epiphany -
>> why the hell is this even a problem?
>>
>> I have probably wasted tens of weeks on the arcana of Jersey, Jackson,
>> XStream to some extent, JAXB...I'm ditching most all of it. It is an
>> obstacle.
>>
>> XStream I actually like for producing and consuming XML. It works
>> nicely. I'll keep it in the toolbox. But for almost everything I do with
>> Java REST, there is no call for Jersey (nor Jackson et al. for JSON
>> (de-)serialization). It's a bunch of extra JARs for no added value.
>>
>> It occurred to me that for over 90 percent of my POJOs I can write
>> reliable toJSON() methods that *will not break* and are fully under my
>> control in a matter of minutes. For anything more I might give
>> simple-json a whirl - it actually has appealing simplicity.
>>
>> And Jersey has got to go. Why do we even drink that Kool-Aid? Once
>> you've got your JSON string a handful of lines of code with an HTTP
>> client will take care of your REST call. A lot more reliable.
>
> I think we need to split the stuff in 3 parts:
> A) server side framework to enable declarative JAX-RS to work in a
>     servlet container
> B) the JSON/POX serializer
> C) client side framework
>
> re A)
>
> I don't hear you argue against that. And I don't recall much
> criticism from other either.
 >
> re B)
>
> You don't like the common libraries. I know several people that
> don't like them either (I don't have so much personal experience).
>
> But is it really the concept that is wrong or is it just the
> implementations?
>
> My guess is still the implementations. I am not too keen on
> toJSON, toXML, toJSONAlternative, toXMLALternative etc.etc.
> on all DTO's.
>
> We may not always like SOAP and all the associated standards,
> but sometimes the "there is only one right way" philosophy
> do make life easier.
>
> re C)
>
> I think it is rather common to use plain HttpClient.
>
> Non-Java client to Java service is probably also a very
> common combination.
>
> Arne

For all of A, B, C, I have no problem with JSON as a data notation. I 
have no major problems with SOAP as a protocol, or with the principles 
of true RESTful web services [1].

For all of A, B, C, it is specifically implementations that I have a 
problem with. Whether language-specific APIs or libraries. JSON is 
simple. SOAP *messages* are usually quite simple (WSDL and schemas might 
not be, but you infrequently occupy your time with those). JSON as a 
payload over HTTP as part of a REST method is simple. SOAP XML via HTTP, 
JMS, SMTP is usually quite simple.

*When we look at what is going back and forth*, that's what is simple. 
What can be, and often is, elaborately over-engineered, clumsy, buggy, 
and not simple are the client and server APIs and libraries.

As to toJSON() or fromXml() type methods, I'm not overly keen on them 
either, for maintainability reasons. We very often have to explain to 
the client or server framework how to handle the DTO<->JSON/XML 
conversions, and annotations are superior to hardcoding for this. Except 
when they're not. :-)

AHS

[1] My uses of REST are almost always trivial. There is no 
hypertext-driven application state because the interactions are 
stateless in the REST sense. They may not be stateless in the system 
(DELETE, PUT, POST) but I never expect the client to follow-up on a REST 
call.

[toc] | [prev] | [next] | [standalone]

#22754

On 3/4/2013 4:53 AM, Arved Sandstrom wrote:
> On 03/03/2013 10:45 PM, Arne Vajhøj wrote:
>> On 3/1/2013 9:34 PM, Arved Sandstrom wrote:
>>> I just had an epiphany today at work. For years upon years I have used
>>> Java libraries which have grown increasingly cumbersome and finicky and
>>> unreliable to do XML or JSON in a REST context...99 percent of which is
>>> actually super-simple.
>>>
>>> The epiphany came when neither Jettison (the default Jersey JSON
>>> library) nor Jackson (which is undoubtedly more modern) could, out of
>>> the box without arcane configuration tweaks, convert a single-item list
>>> into a JSON array. They both just converted the item into a JSON object
>>> and forgot about the array.
>>>
>>> Apparently this catches out a lot of people, judging by googling. The
>>> Jackson solutions are many. The point being - leading to my epiphany -
>>> why the hell is this even a problem?
>>>
>>> I have probably wasted tens of weeks on the arcana of Jersey, Jackson,
>>> XStream to some extent, JAXB...I'm ditching most all of it. It is an
>>> obstacle.
>>>
>>> XStream I actually like for producing and consuming XML. It works
>>> nicely. I'll keep it in the toolbox. But for almost everything I do with
>>> Java REST, there is no call for Jersey (nor Jackson et al. for JSON
>>> (de-)serialization). It's a bunch of extra JARs for no added value.
>>>
>>> It occurred to me that for over 90 percent of my POJOs I can write
>>> reliable toJSON() methods that *will not break* and are fully under my
>>> control in a matter of minutes. For anything more I might give
>>> simple-json a whirl - it actually has appealing simplicity.
>>>
>>> And Jersey has got to go. Why do we even drink that Kool-Aid? Once
>>> you've got your JSON string a handful of lines of code with an HTTP
>>> client will take care of your REST call. A lot more reliable.
>>
>> I think we need to split the stuff in 3 parts:
>> A) server side framework to enable declarative JAX-RS to work in a
>>     servlet container
>> B) the JSON/POX serializer
>> C) client side framework
>>
>> re A)
>>
>> I don't hear you argue against that. And I don't recall much
>> criticism from other either.
>  >
>> re B)
>>
>> You don't like the common libraries. I know several people that
>> don't like them either (I don't have so much personal experience).
>>
>> But is it really the concept that is wrong or is it just the
>> implementations?
>>
>> My guess is still the implementations. I am not too keen on
>> toJSON, toXML, toJSONAlternative, toXMLALternative etc.etc.
>> on all DTO's.
>>
>> We may not always like SOAP and all the associated standards,
>> but sometimes the "there is only one right way" philosophy
>> do make life easier.
>>
>> re C)
>>
>> I think it is rather common to use plain HttpClient.
>>
>> Non-Java client to Java service is probably also a very
>> common combination.
>
> For all of A, B, C, I have no problem with JSON as a data notation. I
> have no major problems with SOAP as a protocol, or with the principles
> of true RESTful web services [1].
>
> For all of A, B, C, it is specifically implementations that I have a
> problem with. Whether language-specific APIs or libraries. JSON is
> simple. SOAP *messages* are usually quite simple (WSDL and schemas might
> not be, but you infrequently occupy your time with those). JSON as a
> payload over HTTP as part of a REST method is simple. SOAP XML via HTTP,
> JMS, SMTP is usually quite simple.
>
> *When we look at what is going back and forth*, that's what is simple.
> What can be, and often is, elaborately over-engineered, clumsy, buggy,
> and not simple are the client and server APIs and libraries.
>
> As to toJSON() or fromXml() type methods, I'm not overly keen on them
> either, for maintainability reasons. We very often have to explain to
> the client or server framework how to handle the DTO<->JSON/XML
> conversions, and annotations are superior to hardcoding for this. Except
> when they're not. :-)

Time to write your own annotation processing library??

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#22758 — Writing ones one Annotation processor (was: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc...)

On Wed, 06 Mar 2013 20:10:22 -0500, Arne Vajhøj wrote:

> Time to write your own annotation processing library??

Even though it was said more in jest, I've been burning to share this
excellent series of blog posts:

<http://deors.wordpress.com/2011/09/26/annotation-types/>


Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#22760 — Re: Writing ones one Annotation processor

On 3/6/2013 8:17 PM, Joerg Meier wrote:
> On Wed, 06 Mar 2013 20:10:22 -0500, Arne Vajhøj wrote:
>
>> Time to write your own annotation processing library??
>
> Even though it was said more in jest,

Only half joke.

It would not be that hard to write a small lib that did some
very basic DTO<->JSON conversion.

Arne

[toc] | [prev] | [next] | [standalone]

#22767

On 03/06/2013 09:10 PM, Arne Vajhøj wrote:
> On 3/4/2013 4:53 AM, Arved Sandstrom wrote:
>> On 03/03/2013 10:45 PM, Arne Vajhøj wrote:
>>> On 3/1/2013 9:34 PM, Arved Sandstrom wrote:
>>>> I just had an epiphany today at work. For years upon years I have used
>>>> Java libraries which have grown increasingly cumbersome and finicky and
>>>> unreliable to do XML or JSON in a REST context...99 percent of which is
>>>> actually super-simple.
>>>>
>>>> The epiphany came when neither Jettison (the default Jersey JSON
>>>> library) nor Jackson (which is undoubtedly more modern) could, out of
>>>> the box without arcane configuration tweaks, convert a single-item list
>>>> into a JSON array. They both just converted the item into a JSON object
>>>> and forgot about the array.
>>>>
>>>> Apparently this catches out a lot of people, judging by googling. The
>>>> Jackson solutions are many. The point being - leading to my epiphany -
>>>> why the hell is this even a problem?
>>>>
>>>> I have probably wasted tens of weeks on the arcana of Jersey, Jackson,
>>>> XStream to some extent, JAXB...I'm ditching most all of it. It is an
>>>> obstacle.
>>>>
>>>> XStream I actually like for producing and consuming XML. It works
>>>> nicely. I'll keep it in the toolbox. But for almost everything I do
>>>> with
>>>> Java REST, there is no call for Jersey (nor Jackson et al. for JSON
>>>> (de-)serialization). It's a bunch of extra JARs for no added value.
>>>>
>>>> It occurred to me that for over 90 percent of my POJOs I can write
>>>> reliable toJSON() methods that *will not break* and are fully under my
>>>> control in a matter of minutes. For anything more I might give
>>>> simple-json a whirl - it actually has appealing simplicity.
>>>>
>>>> And Jersey has got to go. Why do we even drink that Kool-Aid? Once
>>>> you've got your JSON string a handful of lines of code with an HTTP
>>>> client will take care of your REST call. A lot more reliable.
>>>
>>> I think we need to split the stuff in 3 parts:
>>> A) server side framework to enable declarative JAX-RS to work in a
>>>     servlet container
>>> B) the JSON/POX serializer
>>> C) client side framework
>>>
>>> re A)
>>>
>>> I don't hear you argue against that. And I don't recall much
>>> criticism from other either.
>>  >
>>> re B)
>>>
>>> You don't like the common libraries. I know several people that
>>> don't like them either (I don't have so much personal experience).
>>>
>>> But is it really the concept that is wrong or is it just the
>>> implementations?
>>>
>>> My guess is still the implementations. I am not too keen on
>>> toJSON, toXML, toJSONAlternative, toXMLALternative etc.etc.
>>> on all DTO's.
>>>
>>> We may not always like SOAP and all the associated standards,
>>> but sometimes the "there is only one right way" philosophy
>>> do make life easier.
>>>
>>> re C)
>>>
>>> I think it is rather common to use plain HttpClient.
>>>
>>> Non-Java client to Java service is probably also a very
>>> common combination.
>>
>> For all of A, B, C, I have no problem with JSON as a data notation. I
>> have no major problems with SOAP as a protocol, or with the principles
>> of true RESTful web services [1].
>>
>> For all of A, B, C, it is specifically implementations that I have a
>> problem with. Whether language-specific APIs or libraries. JSON is
>> simple. SOAP *messages* are usually quite simple (WSDL and schemas might
>> not be, but you infrequently occupy your time with those). JSON as a
>> payload over HTTP as part of a REST method is simple. SOAP XML via HTTP,
>> JMS, SMTP is usually quite simple.
>>
>> *When we look at what is going back and forth*, that's what is simple.
>> What can be, and often is, elaborately over-engineered, clumsy, buggy,
>> and not simple are the client and server APIs and libraries.
>>
>> As to toJSON() or fromXml() type methods, I'm not overly keen on them
>> either, for maintainability reasons. We very often have to explain to
>> the client or server framework how to handle the DTO<->JSON/XML
>> conversions, and annotations are superior to hardcoding for this. Except
>> when they're not. :-)
>
> Time to write your own annotation processing library??
>
> :-)
>
> Arne
>
>
My next big Java-space web app development effort is going to be 
shifting away from JSF. I've been using the framework for 8 or 9 years, 
and I'm unhappy with it.

My current JSF routine is - once I know what the page flow is, the model 
and viewmodels are thought through, wireframes or the equivalent are 
worked up etc - commences by using my Scala DSL to generate appropriate 
XHTML page and Java managed bean skeletons, which removes over 75% of 
the boilerplate effort. I use a Mojarra JSF (latest version) and 
Primefaces (latest version) combination to implement.

I still find it very tedious. In comparison to JPA, where 2.x really is 
a major capability step up from 1.x, I found that JSF 2.x gave me a 
small number of minor new handy capabilities, but largely formalized all 
the workarounds and custom code that I'd had available since as early as 
2007 or so for JSF 1.1, and later for JSF 1.2. For example, from 2008 
through 2011 I did a lot of JSF 1.x projects using an 
enhanced/customized JSF library (since the ability to extend JSF has 
always been there) that foresaw the majority of 2.x features. I didn't 
even switch over to 2.0 on real jobs until maybe a year after it came 
out, except for experimenting with it, mainly because there was no real 
need. This custom version, that I also enhanced myself, even did proper 
paginated AJAX'd datatables.

I use 2.1 now, like I say Mojarra + PrimeFaces (I've tried ICEFaces, 
RichFaces etc etc, but now prefer PrimeFaces), but when all is said and 
done it takes as much time to develop - page for page, removing the 
effect of me using my DSL - for 2.1 as it did for 1.1. Nothing I can 
think of really takes less time and less effort with JSF 2.x than it did 
with 1.x. Inline row editing is an example: anyone who wanted to do this 
with 1.x worked out a solution early on, and had it in their toolbox. 
That the capability is now provided out of the box by many frameworks 
like Primefaces doesn't remove the fact that I could set up inline row 
editing in 1.x just as quickly.

Sure, all of this is great for new JSF developers - but it's not 
compelling progress for me.

I'm actually not even happy anymore with frameworks that separate the 
whole business out into pages + code (e.g. JSF XHTML + managed bean 
Java, or ASP.NET MVC aspx + C# codebehind, say). I've never worked in - 
or heard of, or encountered - an environment where one team worked on 
pages and another on backing code. It's usually the same developers that 
do both. It's more productive that way. So why 2 different artifacts - 
essentially a page template + the controller/presentation model code - 
to accomplish one thing: a generated page?

While I'm not arguing for the return of classic ASP or classic JSP or a 
general migration over to PHP for everyone (I seriously dislike PHP), 
I'm not dogmatically opposed to a single artifact per generated page. As 
far as I am concerned, by abstracting away as much as we have from a 
servlet producing HTML directly, or CGI scripts or executables doing the 
same thing, we've abstracted away too far. Look at all the problems on 
StackOverflow etc that people are still wrestling with to do basic stuff 
with JSF 2.x. I suppose if you just started with web frameworks last 
year then you don't know any better, but I am not convinced we're better 
off in 2013 than we were in 2003 or close to 20 years ago, actually, not 
when discussing server-side technology.

Part of my thinking is inspired by the Scala DSL I wrote to not 
continually waste my time with JSF boilerplate. It's not a big 
conceptual step from that to a complete DSL that when executed *is* your 
web app. It's not hard to do; a number of languages already support XML 
in code, so your generators use that capability.

Not since Day One have my basic requirements in web pages changed. CRUD 
and datatable capability is 90+ percent of it, always has been, always 
will be. I'd be hard-pressed to think of a single page out of hundreds 
I've written that isn't basically CRUD. 100 percent of the time when I 
work with a JSF XHTML page or an ASP.NET MVC page, all that HTML is 
standardized adornment - it could *always* be generated. Basically, why 
don't I declare (in code) what my pages should do, and do it just once? 
And a Page object knowing how to present itself - isn't that core OO?

I can do all of my tweaking with CSS and JavaScript, as required. 
Usually just CSS, because most of the JS in my vision would be generated 
too.

We call this codebehind/backing bean coding + XHTML page writing a 
"separation of concerns". Well, no, it's not. Not when we routinely 
embed JSF XHTML or ASP.NET MVC ASPX pages with code to the extent that 
we may as well be doing scriptlets. The code we embed may simply be 
viewmodel references and action references, but it's still embedded 
code. To me all of this is simply extra effort for no real gain.

As you might guess I am pretty interested in HTML5 also. :-) Ideally 
that would be the generated product. My gut feeling is that JSF 
evolution will not be able to keep up with the real impact of HTML5 
anyway, another reason to move away.

Just some opinionating. :-) Thinking aloud.

AHS

[toc] | [prev] | [next] | [standalone]

#22787

On 3/7/2013 5:39 AM, Arved Sandstrom wrote:
> My next big Java-space web app development effort is going to be
> shifting away from JSF. I've been using the framework for 8 or 9 years,
> and I'm unhappy with it.
>
> My current JSF routine is - once I know what the page flow is, the model
> and viewmodels are thought through, wireframes or the equivalent are
> worked up etc - commences by using my Scala DSL to generate appropriate
> XHTML page and Java managed bean skeletons, which removes over 75% of
> the boilerplate effort. I use a Mojarra JSF (latest version) and
> Primefaces (latest version) combination to implement.
>
> I still find it very tedious. In comparison to JPA, where 2.x really is
> a major capability step up from 1.x, I found that JSF 2.x gave me a
> small number of minor new handy capabilities, but largely formalized all
> the workarounds and custom code that I'd had available since as early as
> 2007 or so for JSF 1.1, and later for JSF 1.2. For example, from 2008
> through 2011 I did a lot of JSF 1.x projects using an
> enhanced/customized JSF library (since the ability to extend JSF has
> always been there) that foresaw the majority of 2.x features. I didn't
> even switch over to 2.0 on real jobs until maybe a year after it came
> out, except for experimenting with it, mainly because there was no real
> need. This custom version, that I also enhanced myself, even did proper
> paginated AJAX'd datatables.
>
> I use 2.1 now, like I say Mojarra + PrimeFaces (I've tried ICEFaces,
> RichFaces etc etc, but now prefer PrimeFaces), but when all is said and
> done it takes as much time to develop - page for page, removing the
> effect of me using my DSL - for 2.1 as it did for 1.1. Nothing I can
> think of really takes less time and less effort with JSF 2.x than it did
> with 1.x. Inline row editing is an example: anyone who wanted to do this
> with 1.x worked out a solution early on, and had it in their toolbox.
> That the capability is now provided out of the box by many frameworks
> like Primefaces doesn't remove the fact that I could set up inline row
> editing in 1.x just as quickly.
>
> Sure, all of this is great for new JSF developers - but it's not
> compelling progress for me.
>
> I'm actually not even happy anymore with frameworks that separate the
> whole business out into pages + code (e.g. JSF XHTML + managed bean
> Java, or ASP.NET MVC aspx + C# codebehind, say). I've never worked in -
> or heard of, or encountered - an environment where one team worked on
> pages and another on backing code. It's usually the same developers that
> do both. It's more productive that way. So why 2 different artifacts -
> essentially a page template + the controller/presentation model code -
> to accomplish one thing: a generated page?
>
> While I'm not arguing for the return of classic ASP or classic JSP or a
> general migration over to PHP for everyone (I seriously dislike PHP),
> I'm not dogmatically opposed to a single artifact per generated page. As
> far as I am concerned, by abstracting away as much as we have from a
> servlet producing HTML directly, or CGI scripts or executables doing the
> same thing, we've abstracted away too far. Look at all the problems on
> StackOverflow etc that people are still wrestling with to do basic stuff
> with JSF 2.x. I suppose if you just started with web frameworks last
> year then you don't know any better, but I am not convinced we're better
> off in 2013 than we were in 2003 or close to 20 years ago, actually, not
> when discussing server-side technology.
>
> Part of my thinking is inspired by the Scala DSL I wrote to not
> continually waste my time with JSF boilerplate. It's not a big
> conceptual step from that to a complete DSL that when executed *is* your
> web app. It's not hard to do; a number of languages already support XML
> in code, so your generators use that capability.
>
> Not since Day One have my basic requirements in web pages changed. CRUD
> and datatable capability is 90+ percent of it, always has been, always
> will be. I'd be hard-pressed to think of a single page out of hundreds
> I've written that isn't basically CRUD. 100 percent of the time when I
> work with a JSF XHTML page or an ASP.NET MVC page, all that HTML is
> standardized adornment - it could *always* be generated. Basically, why
> don't I declare (in code) what my pages should do, and do it just once?
> And a Page object knowing how to present itself - isn't that core OO?
>
> I can do all of my tweaking with CSS and JavaScript, as required.
> Usually just CSS, because most of the JS in my vision would be generated
> too.
>
> We call this codebehind/backing bean coding + XHTML page writing a
> "separation of concerns". Well, no, it's not. Not when we routinely
> embed JSF XHTML or ASP.NET MVC ASPX pages with code to the extent that
> we may as well be doing scriptlets. The code we embed may simply be
> viewmodel references and action references, but it's still embedded
> code. To me all of this is simply extra effort for no real gain.
>
> As you might guess I am pretty interested in HTML5 also. :-) Ideally
> that would be the generated product. My gut feeling is that JSF
> evolution will not be able to keep up with the real impact of HTML5
> anyway, another reason to move away.

Sounds as if you may like RoR.

:-)

Or if you want to stick in the Java world (not counting
RoR with JRuby) one of:
* Spring Roo
* Myclipse Spring MVC scaffolding
* Myclipse GWT Spring scaffolding

Disclaimer: I have never used any of these, so I have no idea how
good or bad they are.

Arne

[toc] | [prev] | [next] | [standalone]

#22812

On 03/07/2013 12:41 PM, Arne Vajhøj wrote:
> On 3/7/2013 5:39 AM, Arved Sandstrom wrote:
>> My next big Java-space web app development effort is going to be
>> shifting away from JSF. I've been using the framework for 8 or 9 years,
>> and I'm unhappy with it.
[ SNIP ]
>
> Sounds as if you may like RoR.
>
> :-)

Maybe, maybe not. When I said that my web work was basically mostly or 
all CRUD, I was overly simplifying. While ultimately it *is* mostly 
CRUD, there are always business rules and workflow associated with what 
CRUD is going to happen, so the pages may be complex and not just 
straightforward list+add+delete+edit RoR-type pages. Mind you, I only 
looked at RoR once and casually about 3 or 4 years ago.

It might be more accurate for me to say that the web page actions are 
always CRUD-like, they are affecting state of something. That might be 
session state, view state, JPA extended state, or database state (upon a 
commit). Doesn't really matter what state it is.

But the generated HTML might be - often is - quite complex. Not 
predictable by any scaffolding type system.

What I'm getting at is, it seems to me like everyone out there who built 
a web framework got fixated on the idea that you have to have page 
templates *and* code behind. Different artifacts altogether, and you 
always need two or more to implement a delivered page. And considering 
how tightly bound these pairs of template + codebehind usually are, why 
do we have two artifacts anyway? Separation of concerns? No, the things 
are inextricably bound together. Ease of development or maintenance? Not 
bloody likely - you're forever jumping between at least two source files 
to get things done.

So why not just have a single code artifact that implements a page? 
That's one of my arguments.

> Or if you want to stick in the Java world (not counting
> RoR with JRuby) one of:
> * Spring Roo
> * Myclipse Spring MVC scaffolding
> * Myclipse GWT Spring scaffolding
>
> Disclaimer: I have never used any of these, so I have no idea how
> good or bad they are.
>
> Arne
>
I still need to do a lot of research. I am not sure anyone has produced 
what I am looking for.

AHS

[toc] | [prev] | [next] | [standalone]

#22814

On 3/7/2013 7:28 PM, Arved Sandstrom wrote:
> On 03/07/2013 12:41 PM, Arne Vajhøj wrote:
>> On 3/7/2013 5:39 AM, Arved Sandstrom wrote:
>>> My next big Java-space web app development effort is going to be
>>> shifting away from JSF. I've been using the framework for 8 or 9 years,
>>> and I'm unhappy with it.
> [ SNIP ]
>>
>> Sounds as if you may like RoR.
>>
>> :-)
>
> Maybe, maybe not. When I said that my web work was basically mostly or
> all CRUD, I was overly simplifying. While ultimately it *is* mostly
> CRUD, there are always business rules and workflow associated with what
> CRUD is going to happen, so the pages may be complex and not just
> straightforward list+add+delete+edit RoR-type pages. Mind you, I only
> looked at RoR once and casually about 3 or 4 years ago.
>
> It might be more accurate for me to say that the web page actions are
> always CRUD-like, they are affecting state of something. That might be
> session state, view state, JPA extended state, or database state (upon a
> commit). Doesn't really matter what state it is.
>
> But the generated HTML might be - often is - quite complex. Not
> predictable by any scaffolding type system.
>
> What I'm getting at is, it seems to me like everyone out there who built
> a web framework got fixated on the idea that you have to have page
> templates *and* code behind. Different artifacts altogether, and you
> always need two or more to implement a delivered page. And considering
> how tightly bound these pairs of template + codebehind usually are, why
> do we have two artifacts anyway? Separation of concerns? No, the things
> are inextricably bound together. Ease of development or maintenance? Not
> bloody likely - you're forever jumping between at least two source files
> to get things done.
>
> So why not just have a single code artifact that implements a page?
> That's one of my arguments.

It is possible to write plain JSP or PHP with all the code embedded in
the page.

It is usually not considered good, because you mix the UI layout
and the code.

Web frameworks and desktop frameworks (WPF, JavaFX) have been
moving away from that for years.

But the benefit of the separation builds on an assumption that
they will be modified independently - potentially by different teams.

That may make sense in large public facing web sites.

But in an admin web GUI for some business app exposing some basic CRUD
functionality, then it will often be the same person modifying both at
the same time.

I just have a feeling that you will not be happy with an
all code embedded solution either.

>> Or if you want to stick in the Java world (not counting
>> RoR with JRuby) one of:
>> * Spring Roo
>> * Myclipse Spring MVC scaffolding
>> * Myclipse GWT Spring scaffolding
>>
>> Disclaimer: I have never used any of these, so I have no idea how
>> good or bad they are.
>>
> I still need to do a lot of research. I am not sure anyone has produced
> what I am looking for.

That will depend on how perfect a match you are looking for.

Arne

[toc] | [prev] | [next] | [standalone]

#22820

On 03/07/2013 10:24 PM, Arne Vajhøj wrote:
> On 3/7/2013 7:28 PM, Arved Sandstrom wrote:
>> On 03/07/2013 12:41 PM, Arne Vajhøj wrote:
>>> On 3/7/2013 5:39 AM, Arved Sandstrom wrote:
>>>> My next big Java-space web app development effort is going to be
>>>> shifting away from JSF. I've been using the framework for 8 or 9 years,
>>>> and I'm unhappy with it.
>> [ SNIP ]
>>>
>>> Sounds as if you may like RoR.
>>>
>>> :-)
>>
>> Maybe, maybe not. When I said that my web work was basically mostly or
>> all CRUD, I was overly simplifying. While ultimately it *is* mostly
>> CRUD, there are always business rules and workflow associated with what
>> CRUD is going to happen, so the pages may be complex and not just
>> straightforward list+add+delete+edit RoR-type pages. Mind you, I only
>> looked at RoR once and casually about 3 or 4 years ago.
>>
>> It might be more accurate for me to say that the web page actions are
>> always CRUD-like, they are affecting state of something. That might be
>> session state, view state, JPA extended state, or database state (upon a
>> commit). Doesn't really matter what state it is.
>>
>> But the generated HTML might be - often is - quite complex. Not
>> predictable by any scaffolding type system.
>>
>> What I'm getting at is, it seems to me like everyone out there who built
>> a web framework got fixated on the idea that you have to have page
>> templates *and* code behind. Different artifacts altogether, and you
>> always need two or more to implement a delivered page. And considering
>> how tightly bound these pairs of template + codebehind usually are, why
>> do we have two artifacts anyway? Separation of concerns? No, the things
>> are inextricably bound together. Ease of development or maintenance? Not
>> bloody likely - you're forever jumping between at least two source files
>> to get things done.
>>
>> So why not just have a single code artifact that implements a page?
>> That's one of my arguments.
>
> It is possible to write plain JSP or PHP with all the code embedded in
> the page.
>
> It is usually not considered good, because you mix the UI layout
> and the code.
>
> Web frameworks and desktop frameworks (WPF, JavaFX) have been
> moving away from that for years.
>
> But the benefit of the separation builds on an assumption that
> they will be modified independently - potentially by different teams.

That's right, that's the expressed reason for this kind of split.

> That may make sense in large public facing web sites.
>
> But in an admin web GUI for some business app exposing some basic CRUD
> functionality, then it will often be the same person modifying both at
> the same time.

As you noted, there is a class of web apps where different people 
develop and maintain presentation artifacts, and other people work on 
code. Often graphics designers are involved, a full-blown CMS is in 
play, etc etc.

But there are also a great number of business apps where, as you noted 
again, it is the same people creating and modifying everything. All 
developers. There's no advantage - to me, anyway - of having a separate 
page template, and it's actually a hindrance. I gain nothing in 
visualization from having the XHTML template, since it often deviates 
from the rendered output significantly enough that you have to run the 
app and view in the browser anyhow.

> I just have a feeling that you will not be happy with an
> all code embedded solution either.

Never know until you try. :-)

>>> Or if you want to stick in the Java world (not counting
>>> RoR with JRuby) one of:
>>> * Spring Roo
>>> * Myclipse Spring MVC scaffolding
>>> * Myclipse GWT Spring scaffolding
>>>
>>> Disclaimer: I have never used any of these, so I have no idea how
>>> good or bad they are.
>>>
>> I still need to do a lot of research. I am not sure anyone has produced
>> what I am looking for.
>
> That will depend on how perfect a match you are looking for.
>
> Arne

If it's all code I'll at least take a look. If it uses separate page 
templates then it's invariably same-old, same-old. But it doesn't 
otherwise have to be a perfect fit.

AHS

[toc] | [prev] | [next] | [standalone]

#22822

On 08/03/13 09:49, Arved Sandstrom wrote:
> On 03/07/2013 10:24 PM, Arne Vajhøj wrote:
>> On 3/7/2013 7:28 PM, Arved Sandstrom wrote:
>>> On 03/07/2013 12:41 PM, Arne Vajhøj wrote:

[snip]

> If it's all code I'll at least take a look. If it uses separate page
> templates then it's invariably same-old, same-old. But it doesn't
> otherwise have to be a perfect fit.

Well I have also used all manner of nonsense that professes to make 
development easier, smarter, faster, more bug free etc etc when all it 
really so often means is just another load of XML to learn.

We have reverted to the tried and trusted method of getting a wireframe 
from the designers and writing tags to render the output. Works well and 
it's client agnostic. AJAX takes care of any 'web2' type stuff and our 
applications can render output to any interface, even other machines as 
all the important stuff is encapsulated on the server.

This will certainly change when CSS3 and HTML5 become widely 
implemented. Get that funky Canvas thing ... and Websockets ... exciting 
times ahead.

As for REST, well I'm half way through the Fielding dissertation
so I'll form an opinion when I'm done.

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#22825

Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
 
> That's right, that's the expressed reason for this kind of split.

It's not a very good argument after the introduction of CSS, though,
as the division of labour (such as it ever were) has moved to the HTML
/ CSS border.

I think a better argument for maintaining the separation of concern is
that neither Java nor HTML embeds well in the other. On the other
hand, none of the many frameworks that tries to solve the issue have
exactly whelmed me over either.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#22837

On 03/08/2013 02:06 PM, Leif Roar Moldskred wrote:
> Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
>
>> That's right, that's the expressed reason for this kind of split.
>
> It's not a very good argument after the introduction of CSS, though,
> as the division of labour (such as it ever were) has moved to the HTML
> / CSS border.

That's one of the realities that leads me to believe that consolidated 
code objects that produce XML (XHTML) will work, because even die-hard 
grizzled non-web code monkeys like me now rely primarily on CSS for the 
visual appearance of a page.

> I think a better argument for maintaining the separation of concern is
> that neither Java nor HTML embeds well in the other.

In fact (X)HTML and tags don't embed well in each other either. Call JSF 
tags by any other name, they are still tightly coupled to code: they may 
as well be code. Again, I make this observation in the context of what 
we've stated, that very often there are no separate teams working on 
page templates and on backing code.

In fact, a decade ago or more I could've told anyone that. The "other" 
team, the graphics designers, had nothing to do with page templates then 
either, whether HTML or XML or WML or HDML. It's usually been the coders 
who deal with the whole package. A nice example of the framework 
designers being a bit too ivory tower [1].

We don't need to have X(HTML) embedded in the code that programmers 
would normally use. When the Page object, completely written in code, is 
called upon to render, the framework takes care of this. Even with 
current frameworks where we waste so much time writing page templates in 
non-code, the framework still produces 50-90 percent of the final 
rendered page.

> On the other
> hand, none of the many frameworks that tries to solve the issue have
> exactly whelmed me over either.
>
As I pointed out before, and I don't think I am far wrong, none of the 
frameworks has appreciably saved anyone any labour in close to 2 
decades. Given - and this is a big given - something like CSS2+, a CGI 
script or servlet producing raw XHTML, per page, would be as productive 
as the current modern frameworks.

I'm being something of a shit disturber here, but I think I have some 
valid points. I just wasted the best part of 2 days this week on a badly 
documented Primefaces feature that, judging by Googling, has caused 
dozens of other people to waste many days individually themselves. *A* 
feature, a single minor technicality in JSF. Given that the same visual 
effect is readily achievable using CSS, I would have gotten there 
quicker by producing suitable structural XHTML, and styled it.

AHS

1. The J2EE specs assumed right from the beginning that you'd have 
multiple stages of people working on beans. What a joke. Same thing.

[toc] | [prev] | [next] | [standalone]

#22905

On 3/8/2013 7:44 PM, Arved Sandstrom wrote:
> On 03/08/2013 02:06 PM, Leif Roar Moldskred wrote:
>> On the other
>> hand, none of the many frameworks that tries to solve the issue have
>> exactly whelmed me over either.
>>
> As I pointed out before, and I don't think I am far wrong, none of the
> frameworks has appreciably saved anyone any labour in close to 2
> decades. Given - and this is a big given - something like CSS2+, a CGI
> script or servlet producing raw XHTML, per page, would be as productive
> as the current modern frameworks.

Well - I did a lot of CGI back then - and I think you are
exaggerating here.

I was very hard to work with.

> I'm being something of a shit disturber here, but I think I have some
> valid points.

I agree on that.

Web frameworks has gotten more and more complex and even though I
do see significant improvements, then they have not delivered as
promised.

> 1. The J2EE specs assumed right from the beginning that you'd have
> multiple stages of people working on beans. What a joke. Same thing.

<quote>
EE.2.11Platform Roles . . . . . . . . . . . . . . . . . . . . . . . . . 
. . . . . . . . . . . . 19
EE.2.11.1Java EE Product Provider . . . . . . . . . . . . . . . . . . . 
. . . 19
EE.2.11.2Application Component Provider . . . . . . . . . . . . . . . . 20
EE.2.11.3Application Assembler . . . . . . . . . . . . . . . . . . . . . 
. . . 20
EE.2.11.4Deployer . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. . . . . . . . 20
EE.2.11.5System Administrator . . . . . . . . . . . . . . . . . . . . . 
. . . . 21
EE.2.11.6Tool Provider. . . . . . . . . . . . . . . . . . . . . . . . . 
. . . . . . . 21
EE.2.11.7System Component Provider. . . . . . . . . . . . . . . . . . . . 21
</quote>

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#22906

On Mon, 11 Mar 2013 18:07:01 -0400, Arne Vajhøj wrote:

> I was very hard to work with.

Don't be too harsh with yourself, I'm sure you weren't that bad.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#22909

On 3/11/2013 6:27 PM, Joerg Meier wrote:
> On Mon, 11 Mar 2013 18:07:01 -0400, Arne Vajhøj wrote:
>
>> I was very hard to work with.
>
> Don't be too harsh with yourself, I'm sure you weren't that bad.

:-)

Missing 't' .......

Arne

[toc] | [prev] | [next] | [standalone]

#22914

On 03/11/2013 07:07 PM, Arne Vajhøj wrote:
> On 3/8/2013 7:44 PM, Arved Sandstrom wrote:
>> On 03/08/2013 02:06 PM, Leif Roar Moldskred wrote:
>>> On the other
>>> hand, none of the many frameworks that tries to solve the issue have
>>> exactly whelmed me over either.
>>>
>> As I pointed out before, and I don't think I am far wrong, none of the
>> frameworks has appreciably saved anyone any labour in close to 2
>> decades. Given - and this is a big given - something like CSS2+, a CGI
>> script or servlet producing raw XHTML, per page, would be as productive
>> as the current modern frameworks.
>
> Well - I did a lot of CGI back then - and I think you are
> exaggerating here.
>
> I was very hard to work with.
[ SNIP ]

Exaggerating a bit, but maybe not as much as you think. I did CGI in 
both C and in Perl. C not so much fun, but using something like Lincoln 
Stein's CGI.pm, you could generate a lot of maintainable pages quickly - 
I'd argue more quickly than with JSF.

I'll tell you what I think was another high productivity platform: 
ColdFusion, which I used a great deal back in 1999 and 2000.

The other thing is - and I think this is a bad thing - JSF component 
libraries (and I could pick on other frameworks other than just the JSF 
ones) provide so many possibilities that people go crazy with them. 
Often there is no trained graphics designer in the mix to restrain the 
use of "widgets". I've been guilty of this too, because I'm not even 
remotely a graphics designer.

Simpler capabilities often make for better apps and more robust development.

AHS

[toc] | [prev] | [next] | [standalone]

#22915

On 3/11/2013 8:12 PM, Arved Sandstrom wrote:
> On 03/11/2013 07:07 PM, Arne Vajhøj wrote:
>> On 3/8/2013 7:44 PM, Arved Sandstrom wrote:
>>> On 03/08/2013 02:06 PM, Leif Roar Moldskred wrote:
>>>> On the other
>>>> hand, none of the many frameworks that tries to solve the issue have
>>>> exactly whelmed me over either.
>>>>
>>> As I pointed out before, and I don't think I am far wrong, none of the
>>> frameworks has appreciably saved anyone any labour in close to 2
>>> decades. Given - and this is a big given - something like CSS2+, a CGI
>>> script or servlet producing raw XHTML, per page, would be as productive
>>> as the current modern frameworks.
>>
>> Well - I did a lot of CGI back then - and I think you are
>> exaggerating here.
>>
>> I was very hard to work with.
> [ SNIP ]
>
> Exaggerating a bit, but maybe not as much as you think. I did CGI in
> both C and in Perl. C not so much fun, but using something like Lincoln
> Stein's CGI.pm, you could generate a lot of maintainable pages quickly -
> I'd argue more quickly than with JSF.

I used C, Fortran and DCL.

Perl was probably a bit more high level.

> I'll tell you what I think was another high productivity platform:
> ColdFusion, which I used a great deal back in 1999 and 2000.

You know that you can run CF in a Java EE container?

> The other thing is - and I think this is a bad thing - JSF component
> libraries (and I could pick on other frameworks other than just the JSF
> ones) provide so many possibilities that people go crazy with them.
> Often there is no trained graphics designer in the mix to restrain the
> use of "widgets". I've been guilty of this too, because I'm not even
> remotely a graphics designer.
>
> Simpler capabilities often make for better apps and more robust
> development.

For many business admin apps, then all the bells and whistles are
just distractions.

But JSF obviously try to cover even the most sophisticated solutions.

Which I guess is really typical of the official Java (JCP) way of
doing things.

Arne

[toc] | [prev] | [next] | [standalone]

#22917

On 03/11/2013 09:24 PM, Arne Vajhøj wrote:
> On 3/11/2013 8:12 PM, Arved Sandstrom wrote:
>> On 03/11/2013 07:07 PM, Arne Vajhøj wrote:
>>> On 3/8/2013 7:44 PM, Arved Sandstrom wrote:
>>>> On 03/08/2013 02:06 PM, Leif Roar Moldskred wrote:
>>>>> On the other
>>>>> hand, none of the many frameworks that tries to solve the issue have
>>>>> exactly whelmed me over either.
>>>>>
>>>> As I pointed out before, and I don't think I am far wrong, none of the
>>>> frameworks has appreciably saved anyone any labour in close to 2
>>>> decades. Given - and this is a big given - something like CSS2+, a CGI
>>>> script or servlet producing raw XHTML, per page, would be as productive
>>>> as the current modern frameworks.
>>>
>>> Well - I did a lot of CGI back then - and I think you are
>>> exaggerating here.
>>>
>>> I was very hard to work with.
>> [ SNIP ]
>>
>> Exaggerating a bit, but maybe not as much as you think. I did CGI in
>> both C and in Perl. C not so much fun, but using something like Lincoln
>> Stein's CGI.pm, you could generate a lot of maintainable pages quickly -
>> I'd argue more quickly than with JSF.
>
> I used C, Fortran and DCL.
>
> Perl was probably a bit more high level.
>
>> I'll tell you what I think was another high productivity platform:
>> ColdFusion, which I used a great deal back in 1999 and 2000.
>
> You know that you can run CF in a Java EE container?
[ SNIP ]

Yeah. We missed that by just a bit. What's ironic - and what turned out 
to be a really bad decision back then - we had this good web app stuff 
working on CF, and for some reason that completely escapes me now, 
someone decided that switching to J2EE 1.2 was a good idea. It was a 
terrible idea - it directly led to the demise of that startup.

AHS

[toc] | [prev] | [next] | [standalone]

#22918

On 3/11/2013 8:38 PM, Arved Sandstrom wrote:
> On 03/11/2013 09:24 PM, Arne Vajhøj wrote:
>> On 3/11/2013 8:12 PM, Arved Sandstrom wrote:
>>> On 03/11/2013 07:07 PM, Arne Vajhøj wrote:
>>>> On 3/8/2013 7:44 PM, Arved Sandstrom wrote:
>>>>> On 03/08/2013 02:06 PM, Leif Roar Moldskred wrote:
>>>>>> On the other
>>>>>> hand, none of the many frameworks that tries to solve the issue have
>>>>>> exactly whelmed me over either.
>>>>>>
>>>>> As I pointed out before, and I don't think I am far wrong, none of the
>>>>> frameworks has appreciably saved anyone any labour in close to 2
>>>>> decades. Given - and this is a big given - something like CSS2+, a CGI
>>>>> script or servlet producing raw XHTML, per page, would be as
>>>>> productive
>>>>> as the current modern frameworks.
>>>>
>>>> Well - I did a lot of CGI back then - and I think you are
>>>> exaggerating here.
>>>>
>>>> I was very hard to work with.
>>> [ SNIP ]
>>>
>>> Exaggerating a bit, but maybe not as much as you think. I did CGI in
>>> both C and in Perl. C not so much fun, but using something like Lincoln
>>> Stein's CGI.pm, you could generate a lot of maintainable pages quickly -
>>> I'd argue more quickly than with JSF.
>>
>> I used C, Fortran and DCL.
>>
>> Perl was probably a bit more high level.
>>
>>> I'll tell you what I think was another high productivity platform:
>>> ColdFusion, which I used a great deal back in 1999 and 2000.
>>
>> You know that you can run CF in a Java EE container?
> [ SNIP ]
>
> Yeah. We missed that by just a bit. What's ironic - and what turned out
> to be a really bad decision back then - we had this good web app stuff
> working on CF, and for some reason that completely escapes me now,
> someone decided that switching to J2EE 1.2 was a good idea. It was a
> terrible idea - it directly led to the demise of that startup.

If you liked it back then, then you could give it a try today!

There is a free open source implementation available:

http://sourceforge.net/projects/smithos/

Arne

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web