Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc...

Reply
Thread Tools

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

 
 
Arne Vajh°j
Guest
Posts: n/a
 
      03-07-2013
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


 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      03-07-2013
On 03/06/2013 09:15 PM, Arne Vajh°j wrote:
> On 3/3/2013 10:11 PM, Arved Sandstrom wrote:
>> On 03/03/2013 10:57 PM, David Lamb wrote:
>>> On 03/03/2013 9:47 PM, Arne Vajh°j wrote:
>>>> On 3/2/2013 1:11 AM, Kevin McMurtrie wrote:
>>>>> SOAP is one of the worst widely adopted protocols ever. It makes LDAP
>>>>> seem sensible. Just say "no."
>>>>
>>>> It works.
>>>
>>> That doesn't negate what Kevin said; it could "work", as in do useful
>>> stuff, while still being the worst widely adopted protocol. I don't know
>>> enough about SOAP to have a personal opinion, though.
>>>

>> As a model of RPC it makes me want to re-embrace CORBA. It's badly
>> designed.
>>
>> Having said that, if you work with simple subsets it's understandable,
>> robust, and very widely supported. The use of XML is very defensible,
>> IMO.
>>
>> I've seen plenty of much more terrible protocols. SOAP doesn't even come
>> close to some of the Cthulhian mind-blasting horrors I've dealt with.

>
> 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
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      03-07-2013
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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      03-07-2013
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


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      03-07-2013
On 3/7/2013 4:08 AM, Arved Sandstrom wrote:
> On 03/06/2013 09:15 PM, Arne Vajh°j wrote:
>> On 3/3/2013 10:11 PM, Arved Sandstrom wrote:
>>> On 03/03/2013 10:57 PM, David Lamb wrote:
>>>> On 03/03/2013 9:47 PM, Arne Vajh°j wrote:
>>>>> On 3/2/2013 1:11 AM, Kevin McMurtrie wrote:
>>>>>> SOAP is one of the worst widely adopted protocols ever. It makes
>>>>>> LDAP
>>>>>> seem sensible. Just say "no."
>>>>>
>>>>> It works.
>>>>
>>>> That doesn't negate what Kevin said; it could "work", as in do useful
>>>> stuff, while still being the worst widely adopted protocol. I don't
>>>> know
>>>> enough about SOAP to have a personal opinion, though.
>>>>
>>> As a model of RPC it makes me want to re-embrace CORBA. It's badly
>>> designed.
>>>
>>> Having said that, if you work with simple subsets it's understandable,
>>> robust, and very widely supported. The use of XML is very defensible,
>>> IMO.
>>>
>>> I've seen plenty of much more terrible protocols. SOAP doesn't even come
>>> close to some of the Cthulhian mind-blasting horrors I've dealt with.

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

> 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


 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      03-08-2013
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

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      03-08-2013
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


 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      03-08-2013
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

 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      03-09-2013
On 03/08/2013 02:06 PM, Leif Roar Moldskred wrote:
> Arved Sandstrom <(E-Mail Removed)> 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 **** 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.
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      03-11-2013
On 3/8/2013 4:49 AM, 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:
>>>> 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.

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

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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Jaxb java.lang.NoSuchMethodError com.sun.xml.bind.util.AttributesImpl.getIndexFast Anna Java 0 06-04-2006 10:58 PM
JAXB : expecting an automatical control in java source when restrictions are specified in XML schema Jean-Marie Condom Java 2 11-26-2004 09:19 AM
JAXB: Mapping XML to Existing Java Objects?? John Davison Java 3 07-26-2004 10:53 PM
Can JAXB be used to get a Java representation of an XML Schema? SOndei Java 0 01-15-2004 09:20 AM
XML to java using JAXB ? Petterson Mikael Java 0 09-02-2003 01:50 PM



Advertisments