• Post Reply Bookmark Topic Watch Topic
  • New Topic

Unable to understand the weird syntax Netbeans example  RSS feed

 
udaya krishna
Ranch Hand
Posts: 65
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I recently starting playing around with the Netbeans code , and while going through the sample JsfJpaCrud project that came bundled in along with the IDE, I found this weird syntax that was used in


as below

can anybody explain me what exactly is happening here? I am sharing everything that I understand as below

JsfUtil is the class and getAsConvertedString is the method inside the class JsfUtil .But as per my understanding <f:param> takes name and value as parameters.
I could understand the name part in the above line , but not so sure about the value part.Can anybody explain what is happening?

Thanks in advance
Udaya Krishna
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Somebody is committing an atrocity.

First, an editorial comment: JSF View Templates are supposed to be static maps of the UI display. The presence of f:param is often an indicator that someone is polluting the MVC Separation of Concerns and putting executable code in the View Template. That makes the program more inflexible, more expensive to maintain.

The value attribute of the EL clause, as is the case for "value=" attributes in general in JSF is defined as a JEE Expression Language (EL) expression. The full syntax and operating rules for EL are defined as part of the JEE spec, and I won't go into them here, except to say that this particular abomination is a very complex expression. Let me shred it with all the contempt that it deserves:


First you have the "#{}" operator. This indicates that the enclosed text will be parsed and executed as an EL expression with variable substitution.

Then you have the anchor object. Despite the name ("jsfcrud_class"), it's NOT a class, it's an instance of a class. And poorly-named as well, since the Java standard for naming is camelCase, not C-style with underscores. At least the initial letter of the object name wasn't capitalized. Initial capital is used to indicate a class name, initial lower-case an instance, property or method name. JSF's annotation process operates assuming that those conventions are being honored.

OK, now to the next segment:


This is bad because EL interprets clauses in the form "['xyz']" to mean that the anchoring object is a Map-style collection. It assumes that "[123]" would be an array object with index (relative to 0) of 123.

While it is technically possible for a backing bean object to be an instance of a Map, it is not wise to do so. And it's flat impossible, I think, to make a backing bean be an array object. Thus, a better approach would be to make the Map be a named property of the backing bean, not the actual base class of the backing bean itself.

So now we end up with a real mess. The jsf_crud Map is searched and the object filed under the key "jsf.util.jsfUtil" is retrieved. That object is expected to have a MAP property named "jsfcrud_method". Again, violating Java's standards for name syntax. This map is then searched for a property which is a backing bean named "item". Note that the entire bean here is considered to be a simple object, for example, a java.lang.String. This object is used as an index into the object returned from the jsfcrud_method map, and itself should also be a Map. Are you with me? Because I'm getting pretty confused here myself!

OK, Now this map-within-a-map-within-a-map (give or take a few maps) is itself indexed by the value returned from the backing bean "customer" doing a property fetch for its "converter" property. The closest thing to sanity we've seen yet.

And that object in turn, should have a property named "jsfcrud_invoke", which - yet again - violates naming syntax conventions.

Needless to say this horrid construct is going to be a total to debug and maintain. Which is why I recommend doing most of the computing in a backing bean and making the EL itself as simple as possible. For example:


Do all the map-chasing in the "get" method getNastyExpressionResults() and you'll be able to set debug breakpoints in case things don't come out as expected. Better yet, make getNastyExpressionResults() cache the results so you don't end up having to re-compute the whole thing repeatedly. JSF may invoke a give property "get" method 5 or 6 times for a single page request on a single EL expression.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are likely to find such constructions in generic CRUD projects that are meant to provide CRUD functionality without the developer needing to write any pages.
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
E Armitage wrote:You are likely to find such constructions in generic CRUD projects that are meant to provide CRUD functionality without the developer needing to write any pages.


Which is one of the failings of the "any-monkey-can-do-it" development frameworks.

Any monkey can press a few buttons to get a one-size-fits-all solution. But the monkey won't understand how to customize it when the inevitable "It's great, but can you do this one simple thing?" comes back from the users.

And for the really bad monkey frameworks, you get constructs like this, which even an expensive skilled expert will struggle with.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's okay because the frameworks come with a discounted ten million dollar per year license. You also get three consultants to help you setup your project for only a couple of thousand dollars per hour. The slight drawback being that the rest of your developers will now spend all their time fighting the framework to try to get it to do what business actually want. 90% of the functionality will finally be delivered using hacks that by pass the whole thing.
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
E Armitage wrote:That's okay because the frameworks come with a discounted ten million dollar per year license. You also get three consultants to help you setup your project for only a couple of thousand dollars per hour. The slight drawback being that the rest of your developers will now spend all their time fighting the framework to try to get it to do what business actually want. 90% of the functionality will finally be delivered using hacks that by pass the whole thing.


You win. I've ceded my cynic's crown to you.

Congratulations on your recent elevation to Rancher, BTW!
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:
Congratulations on your recent elevation to Rancher, BTW!

thanks. I read something about it somewhere. I don't have cows but I can give them to others ... should be fun.
 
udaya krishna
Ranch Hand
Posts: 65
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Phew!! Initially I was disappointed that my post did not get response for a couple of days.Even got me thinking it might be a stupid question to ask.Thanks Tim for the detailed explanation.Initially I was hoping to follow and build on the project that came in bundled with Netbeans because it would have followed Java "standard" way of coding ,apparently I was wrong!!May have to take some other route then.

Thanks
Udaya Krishna.a
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We're all unpaid volunteers here, so instant responses aren't something you can count on.

Then again, paid support hasn't exactly impressed me for many, many years now. At least we're not monkeys-with-scripts, and we don't send you to Phone Menu Hell.

I won't say that there aren't stupid questions, but it's a fundamental policy that we do not permit flaming of people just because their questions are "stupid". We try and respond to all questions, and about the worst that can be said is if someone really, truly cannot grok things (or refuse to help themselves), we might give up and walk away at some point.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!