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

  • Thread starter Arved Sandstrom
  • Start date
A

Arne Vajhøj

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
 
A

Arved Sandstrom

If one expose a SOAP/HTTP service implemented in language X and
generate a client stub for language Y from the WSDL, then there
is a pretty good chance that it will just work.

Arne
That's true. You can also enhance your chances of success by:

1) working with SoapUI to visualize the XML for relevant
request-response pairs in your scenario. This is particularly helpful
when working with WS-Security;

2) turn on request-response logging for your SOAP implementation, so you
can see the XML that is generated by your client code + client stubs,
plus the service response. Usually pretty simple, in CXF it is
programmatically 2 lines of code.

You can save a lot of wasted time by verifying the actual XML in play.

AHS
 
A

Arved Sandstrom

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
 
A

Arne Vajhøj

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
 
A

Arne Vajhøj

That's true. You can also enhance your chances of success by:

1) working with SoapUI to visualize the XML for relevant
request-response pairs in your scenario. This is particularly helpful
when working with WS-Security;

2) turn on request-response logging for your SOAP implementation, so you
can see the XML that is generated by your client code + client stubs,
plus the service response. Usually pretty simple, in CXF it is
programmatically 2 lines of code.

You can save a lot of wasted time by verifying the actual XML in play.

And to me that is pretty good.

Arne
 
A

Arved Sandstrom

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
 
A

Arne Vajhøj

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

Arved Sandstrom

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. :)
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
 
A

Arved Sandstrom

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

Arne Vajhøj

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. :)

True.

But still.
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.

If you need more that the very simple DB CRUD, then scaffolding will
not solve your problem.

But in the RoR and clones world they are not as afraid of <% %> as
in the Java world.

Arne
 
A

Arne Vajhøj

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 consider the distance CSS-HTML much smaller than HTML-code.

Of course I could be wrong. I still write mostly 2.0. :)
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.

Some problems are just hard to solve.

O/R is not easy either.

Arne
 
A

Arne Vajhøj

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
 
L

Lew

Stefan said:
One might consider HTML code. For example, this
http://web.archive.org/web/20040428174214/http://www.geocities.com/flo_kreidler/tictactoe.html

is an interactive game of »tic tac toe« written in HTML
(no scripting involved).

But such examples are so rare that I actually have to
trouble archive.org to get one!

Being as this is cl.java.programmer, it stands to reason that in this context "code" means Java.

It is good to be precise, though it doesn't alter the validity of Arne's point given what was meant.
 
A

Arved Sandstrom

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
 
A

Arne Vajhøj

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
 
A

Arne Vajhøj

Being as this is cl.java.programmer, it stands to reason that in this context "code" means Java.

It is good to be precise, though it doesn't alter the validity of Arne's point given what was meant.

Java is obvious given the group and the starting point of the discussion.

But it can easily be generalized to all languages of that type
(variable, operators, if, loops etc.).

Arne
 
A

Arved Sandstrom

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top