Showing posts with label JSF. Show all posts
Showing posts with label JSF. Show all posts

Thursday, July 22, 2010

Trinidad JavaScript

Trinidad JavaScript

In short ?
Bad,obsolete,space consuming,sub-optimal .... practices,
in the order discovered.....
judged by my average JS knowledge....

  1. everything in global scope
  2. using new Array()
  3. var; var; var;
  4. Browser detection (sniffing)

  5. Useless chars eg: typeof (elem) == "string"
  6. ... this makes no sence to continue.....
Shocking:
TrUIUtils.createCallback = function(thisObj, func) {
 // create a function that sets up "this" and delegates all of the parameters
 // to the passed in function
 var proxyFunction = new Function(var f=arguments.callee; return f._func.apply(f._owner, arguments);");

 // attach ourselves as "this" to the created function
 proxyFunction._owner = thisObj;

 // attach function to delegate to
 proxyFunction._func = func;

 return proxyFunction;
}
TrUIUtils._cssToJs = function(prop) {
 var jsProp = '';
 var upperNext = false;
 for (var c = 0; c < prop.length; c++) {
  if (prop.charAt(c) == '-') {
   upperNext = true;
   continue;
  }

  if (upperNext) {
   jsProp += prop.charAt(c).toUpperCase();
  }
  else {
   jsProp += prop.charAt(c);
  }

  upperNext = false;
 }
 return jsProp;
}
I had to stop after while... ... since this could be book of "JavaScript antisamples". I have no idea about the libs origin, they mention IE 4 versions, however Trinidad claim support to 6+, I belive a lot of code is "ported" from some other languages with little JS knowledge or care, or comes from aged libs written in the dark and deep web history. I have to quote Mr.D: http://javascript.crockford.com/style1.html
There are no good texts on JavaScript programming. Most of the people on the web who are producing JavaScript programs learned it by copying really bad examples from bad books, bad websites, and bad tools. We have an amazingly good community of JavaScript programmers here, but still we can benefit from better practice of style.

META and Content-Type and Wisdom of JDeveloper

g define:wizard (first hit)
someone who is dazzlingly skilled in any field

Ok then this already mentioned
"JDeveloper New JSF Page" wizard is not skilled in HTML .

In HTML which the wizard is claiming to produce (and twice !, by duplicated DOCTYPE ;-)
the META tag should not be closed (NET-enabling start-tag requires SHORTTAG YES).

However in .jspx (which is XML) you need to close it.

Simple workaround, that should work:

<![CDATA[
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
]]>


BTW: why this meta is not part of trh:head rendering and must be specified manually in jspx markup ?

How many additional steps I have to do to produce valid HTML with these RAD tools ?

HeadRenderer (org.apache.myfaces.trinidadinternal.renderkit.core.xhtml)

This is snipped from trinidad-1.2.12 source code.

String title = getTitle(bean);

if (title != null)

{
rw.startElement("title", null);
rw.writeText(title, null);
rw.endElement("title");
}

// Write the META generator tag
_writeGeneratorTag(context);


First is very wrong from HTML validity point of view:
Validation Error: end tag for "HEAD" which is not finished
....
....For instance, in HTML the head element must contain a title child element...

Second which is unconditional write of

<meta name="generator" content="Apache MyFaces Trinidad">

is at least "unwanted" from "security" point of view.
However trinidad JSF style is so obvious that underlying technology
does not have to bue guessed the hard - "metadata generator way".

Of course, this can be fixed by implementing custom renderer, but...
wasn't trinidad designed to save my time in "usual situations" (at least ) ?

Please change the "if order" and make possible to turn off META generator tag.

Double DOCTYPE, jsp:output, trh:html (trinidad) and JDeveloper wizards

This the result when you click "new JSF Page" "wizard"
and use "*.jspx" and "Render in mobile device" option.


<?xml version='1.0' encoding='UTF-8'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:trh="http://myfaces.apache.org/trinidad/html"
xmlns:tr="http://myfaces.apache.org/trinidad"
xmlns:dvtt="http://xmlns.oracle.com/dss/trinidad/faces">
<jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
doctype-system="http://www.w3.org/TR/html4/loose.dtd"
doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
<jsp:directive.page contentType="text/html;charset=UTF-8"/>
<f:view>
<trh:html>
....


This however has one major problem,
produces invalid HTML markup with DOUBLED DOCTYPE.


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html dir="ltr" lang="en-US">
....


This is because one is produced by
jsp:output
and another by
thr:html + org.apache.myfaces.trinidad.core renderkit
(which is default for JDeveloper 11.1.1.3.0 and "ADF Mobile")
It seems just like coincidence that both are the same (read more...)

Solution:
As far as I hnow, the thr:html does not have "none" option for "Mode"
see http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/trh_html.html
So the best is to remove all doctype-* from jsp:output.
Actually if reading the JSP spec for omit-xml-declaration, you can remove whole
jsp:output because:
omit-xml-declaration....
The default value for a JSP document that has a jsp:root element is “yes”.

To bring some more info: the actual DOCTYPES rendere for MSIE 7.0 with
various swiches are:


default (damned again ?):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
S S A A A A A A Q

quirks:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Q Q Q Q Q Q Q Q Q

strict (this should be default in 2010 !!!):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
S S S S S A A A A


The letters are modes for specific browsers taken from:
http://hsivonen.iki.fi/doctype/

Wednesday, July 21, 2010

JDeveloper 11g and encodings (Damned Default)

After fresh instalation JDeveloper will produce new JSPX pages that may look like this.

<?xml version='1.0' encoding='windows-1252'?>
.....
<jsp:directive.page contentType="text/html;charset=windows-1252"/>



This 1252 seems to me like "unwanted legacy".

Tools/Preferences/Environment/encoding:
Encoding
Use to select an encoding value. The default is CP1252.
Once you have selected a value, all new files will be created with the new encoding, and the new encoding will be used to open and save files without encoding tags.
Note that XML files and JSP 2.0 documents (XML compliant files)
must include an appropriate XML encoding declaration on a per-file basis.
For details refer to the W3C XML specification.
You can expand the encodings
in this list by appending new
encoding definitions to the encodings.xml file, found in the jdev/bin directory. This XML file contains a list of mappings from Sun JDK to IANA encoding names.
Note that files already open in JDeveloper will not be opened with the new encoding. To change the encoding used to read open files, close the files and reopen them after changing the encoding value here. Also note that files with encoding tags will always be opened and saved using the specified tags, and not JDeveloper's encoding.

This is tricky, half true, or buggy ...
I have tried to make a new page in an existing project and again the 1252.
Then I have tried new page in different project and UTF-8.

Beware:
There are two more "Character Encoding" (at least) in Project Preferences.
XML.encoding and JSP.charset in JSF pages seems to be controlled by
Project Preferences/Compiler/JSP.

WorstCase:
So If you have already created projects change those, and
manualy fix text in files and if you have non ascii markup in the text, resave all files as UTF-8 as well ;-))