Joshua Hewitt

Greenhorn
+ Follow
since Sep 28, 2007
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Joshua Hewitt

(I think I might not have explained the EL bit properly. I definitely would avoid it to add any kind of logic in the XHTMLs.)

What do you mean code logic in the views? The original HTML/CSS/JS mockups only contain view, no logic. Same goes for the JSF that comes out of that. All logic stays in the Java: view in the BBs, business in the EJBs and persistence in the EMs.

When I talk about EL I mean just simple outputs, to just use #{text} instead of <h:outputText value="#{text}" /> unless you really need <h:outputText/> for some reason (eg, rendered or escape attributes). I'd even argue that if you get an HTML mockup with <span class="warn">Text</span> it's easier for everyone if you just change that to <span class="warn">#{text}</span> rather than <h:outputText value="#{text}" styleClass="warn" /> when converting it to JSF. Less to think about, less work, less mistakes, more like original mockup, easier to change framework in the future.

I see your point about rendering in a different format. That is definitelly one to add to my "or am I missing something?". Currently we only need HTML and JSON outputs, so it is not an issue. But it might be.

My main point is that, assuming I would rather tie myself to HTML than JSF (this is the fourth MVC framework I have used, and HTML has changed little in all this time), there is no weirdness in avoiding "useless" HTML abstractions provided by JSF, no? There is nothing inherently wrong when I tell our developers to use <a/> instead of <h:link/> unless they have a reason to do so (for example if they were to use an outcome instead of a straight href then yes, use the JSF tag - as long as it isn't the JavaScript-only <h:commandLink/>). Sure, we use h:dataTable and h:panelGroup when it makes sense, for region updating thru AJAX, for complex list/details interfaces etc. But in most cases we don't need it, so I say we just leave the original HTML.
6 years ago
JSF
This is a summary of our front-end development process:
- designers create PNG mockups
- UXers create HTML mockups
- developers create final JSF

Now, these HTML mockups are pretty complete. They use all our in-house JavaScript widgets, production CSS files, responsive design, accesibility requirements, SEO-friendly code, proper semantics etc. So basically the final HTML we need from the JSFs has to nail these mockups, otherwise widgets might not work, styles might not appear correctly, accesibility errors might crop in and SEO might suffer. The developers tend to have limited experience in HTML/JavaScript/CSS/accesibility, especially compared to the UXers, so the less they can do to screw up the HTML the better.

With this in mind we tell our developers to just convert the very minimum to JSF. So that basically means forms & form elements and the occasional loop. For example we tell them to avoid h:dataTable and just use the given HTML table and a loop - for some reason (probably lack of experience) we found it very difficult to nail the right HTML in terms of thead, tbody, th and td (or to get a rowspanned "There are no results" output for empty lists). We even tell them to use straight EL instead of h:outputText (unless they really need it) for i18n literals or form outputs. Then there is the added complication in that we use HTML5 (currently using a RenderKit for that). I also prefer to avoid tying my HTML to a given technology: I don't want my JavaScript/CSS to depend on JSF (or PrimeFaces or whatever) output, I want it to depend on what we consider the "correct" HTML in terms of semantics (ie, unobtrusive frameworks).

Would you say this is a correct strategy? I find it helps reduce developer workload (less to convert), reduces front-end errors (less to screw up), and might it also reduce memory footprint on the server (less component tree)? Or am I missing something?
6 years ago
JSF
I realise that classes are mostly for styles (which I guess is the reason why, as class is a reserved name, in frameworks they end up being called styleClass), but the HTML4 specification says they serve another purpose, "For general purpose processing by user agents". In Microformats, for example, class names are used to add semantics. I see no reason why it is wrong to use class names to mark validation rules. Unless of course there is a better alternative (such as the mechanisms provided by HTML5 - which we will be migrating to sooner rather than later I hope).

I know you can add JSR303 validation tags to EJBs, but doesn't it feel wrong for EJBs containing business logic? I'm not sure about that, it's just a gut feeling. Will look up a bit more on the matter.

Back to the original topic ;-) I've just seen what you were talking about getting the value ValueExpression, something like component.getValueExpression("value") and start messing around from there, no? If I work out something useful I'll post it...
8 years ago
JSF
Tell me about it ;-)

But I'm not invading UI territory (well, not too much). I see class simply as a marker, be it to apply styles or anything else ("cofiguration" for validation in this case). Obviously the way to go is to make use of HTML5 form input attributes, and data-* attributes for things it may not cover, but I don't see adding classes as too invasive. UI designers can still use styling classes like "pinkBackgroundWithFloweryBorder" on an input, and JSF will just add a "required" or "email" to the list of classes (still leaving the original styling classes). The only class the back-end adds that changes style is "error" (red text etc). But as I am also designing the UI architecture I have notified myself ;-)

I'll see what I can do about avoiding DTOs (poor guys, so hated when all they are is simple beans with just getters & setters), but there will be cases where we don't have a managedBean or a JPA entity, and I have to chuck data around somehow. I take it that JSR 303 validations on a "proper" buisiness EJB is a no-no.
8 years ago
JSF
I'm trying to avoid programmers having to think about putting the styleClass on the tag, which is why right now I hook it in a RenderKitWrapper. I'm still in experimental mode, if it gets too hairy it may all get chucked in favour of using Prime/Ice/Rich faces instead (though I'm worried about accessibility in those frameworks - we have a legal obligation to be AA).

Flying wildly off-topic now ;-) DTOs are also controversial amongst us (and I'm sure the source of much heated debate in various posts in this forum). It looks like we will need them for the legacy back-end, and for the new stuff we'll use the JPA entities as DTOs. Though there may be a need for DTOs as a sort of fa├žade to various JPAs in less CRUD-like situations. Will have a ganders to see what others are doing...
8 years ago
JSF
There seemed to be a decent match between them and JSR303, plus I can create my own Constraint/ConstraintValidators for anything they might chuck at me. Even the JSF valitators probably weren't going to be enough.

So you are putting UI validation based on annotations on your JPA (or similar) entities? Sounds like the way to go. But we will probably have DTOs in the way (though I guess something could be done about that), plus legacy code which doesn't use ORM.

Right now I'm on plain 'ol HTML4/XHTML1. The final output shoves all the "configuration" into the input's class: input tyle="text" class="min4 max8 required". May move onto HTML5 but I'm pretty new at this - only just started to muck around with the renderkit a few days ago and saw it as a good way to get HTML5 support.

Ouch, introspection sounds nasty. In our case it might be #{bean.property} or #{bean.dto.property}, though as you say you never know what a developer can concoct.

...and then I have to work out a transparent way to execute the validation for JAX-RS requests...
8 years ago
JSF
First a bit of background...

I want to implement a bit of simple client-side validation using JavaScript/jQuery. The way it works is looking for certain classNames on the form inputs such as min3, required...

Then I wanted to make this transparent to the programmer, so I extended the renderkit so for each component it looks at it's validators and injects these classNames:
@Override
public void writeAttribute(String name, Object value, String property) throws IOException {
Object newValue = value;
if (BKRenderKit.CLASS_NAME.equals(name)) {
UIComponent component = UIComponent.getCurrentComponent(FacesContext.getCurrentInstance());
if (component instanceof UIInput) {
for (final Validator validator : ((UIInput)component).getValidators()) {
if (validator instanceof LengthValidator) {
final int min = ((LengthValidator)validator).getMinimum();
final int max = ((LengthValidator)validator).getMaximum();
if (min > 0) {
newValue = newValue + " min" + min;
}
if (max > 0) {
newValue = newValue + " max" + max;
}
//...
}
}
}
super.writeAttribute(name, newValue, property);
}

So far so good. However, we now want to move away from JSF validators and use JSR 303 validation on the beans (the idea is to reuse code for JSON REST interfaces).

Does anybody know if there is there any way to get a list of the JSR 303 validators off a UIInput?
8 years ago
JSF
All the various singleton implementations seem to have some downside:
- not thread safe
- performance issues when synchronising
- overhead when using eager instantiation
- double-checked locking broken

But doesn't the following singleton get round all this issues?

public class Singleton {
private static class SingletonHolder {
private final static Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}

This _is_ thread safe, no? Plus it uses lazy instantiation, isn't broken, and has no performance issues. If you're not worried about "exotic" things such as subclassing, deserialization, distributed environments (multiple JVMs), multiple classloaders (eg iPlanet) etc isn't this the "perfect singleton"? I'm surprised this implementation doesn't appear hardly anywhere on the web. Am I missing something?