The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

I was pleasantly surprise about the email announcing a new MEAP version with an added chapter about forms and validation, because I am just working on implementing/tightening the validation in our app.

However I found the chapter not very helpful. It doesn't give any more insight than the tutorial on the ng site.

How about integration custom validation logic? (The checksum on the part number must be correct.)
How to deal with cross-field validation? (Vacation start date must be before end date.)
How about doing server side checks? (The user name must be unique among all registered users.)
How to deal with errors that are only send by the server when trying to save? (Regardless on how good the validation is, there may always be errors that occur only when trying to actually perform the action. (Like the user name has been taken by somebody else after the last validation run.))

By the way: A special quirk was noticed by our testers, for which there seems to be no workaround: On Chrome (which implements html 5 validation attributes), if you have an 'input type="number" ' which is not also "required" then it can have alphabetic characters in it, and still is valid to ng.
In v6, in "8.1.1 Extending HTML Form Elements", the book says
It is also a really good idea to add the novalidate flag to the form element so that it does not submit.
That does not make any sense.
It should better read something like this:
It is also a really good idea to add the novalidate flag to the form element so that the browser skips its own validation of HTML 5 attributes like min/max and we can do cross-browser validation that works uniformly across standard validation attributes and custom validation logic.
Ok, so after searching on the sass web site some more:
haml and sass have become separate not so long ago. There isn't yet a separate final gem for sass. To install the prerelease use
gem install sass --pre

Any ETA for the release version?
Appendix A, 1.1.3 says
To install the latest version of Sass:
$gem install sass
However for me that only results in
ERROR: Could not find a valid gem 'sass' (>= 0) in any repository
Installing compass with "gem install compass" works fine and automatically installs haml, too, which includes sass, if I read the docs here correctly:

At least "sass -v" works fine after installing just the compass gem.
Maybe the bundling of haml with sass is new?
Chapter 10 (Charts) should mention right on the first page that Flash is needed to display charts.
For us (and probably many others) this makes the ExtJS charting features completely useless: Company policy forbids the usage of Flash.

Currently the chapter text can even be interpreted as meaning that flash is not necessary at all:
> What makes Charts in the framework so cool is that you need not have any
> Flash experience to get this stuff to work for you.
> As we’ll see, everything will be done via JavaScript.

I really don't get why such an important features isn't implemented in pure JavaScript (using maybe Raphaël as foundation technology).

A general remark about the book: IMHO quite a lot of anecdotes and sales pitches could be removed to make it more concise. After all this in an "in Action" book, right?

Rather I would like to hear about ExtJS's rough edges. (For example just this week I was perplexed to note that the default grid cell renderer leaves the door wide open to XSS attacks).
Thanks for the quick answer.

No, I am not saying that the text is incorrect, just very easy to misunderstand if you you are not already familiar with charting.
It is missing a statement that using ExtJS's charting requires each client browser to have flash installed.

BTW: I am absolutely with you: ExtJS is the coolest technology I used for the last couple of years smilie

I don't really want to go into the discussion again (see the lengthy ExtJS forum discussion) which part of the system should be responsible to prevent XSS attacks, but can't help making a couple of remarks:
The point is exactly that the cell renderer is not only "spitting out data" - it can be misused to spit out code.
I was coming from Java Server Faces (conceptually surprisingly similar to ExtJS) where every output that is made by JSF components is escaped unless escape="false" is explicitly added. There is absolutely no harm done by this strategy and it is much safer by default.
The XSS prevention cheat sheet from the OWASP project (arguably the authority on this issue) names output encoding as "rule #1" (there's a rule #0 saying that you should inject dynamic text only to defined location):
Anyway, I think adding a prominent note somewhere (to the grid/tree chapters?) is a good idea:
ExtJS by default does not encode data in a grid cell.
When the data comes from any untrusted source (such as user input) then to prevent XSS attacks you must scrub the data on the server side and/or use a custom renderer that escapes the data prior to rendering.
I have just started to use the Ext.ux.LiveGrid component ( )
It's a very nice addition to ExtJs builtin components. But it wasn't that easy too find in the first place and getting started was a little hard, because documentation was close to nil (except for comments in source code).

I wonder what other useful plugins are there, that I don't yet know about.

It would be great if there were a short list of the most popular/useful extensions with selected examples.
Oh, but it does work for HTML/CSS/JavaScript, see for a tiny example from your book.

BTW the example used other than the code apostrophe/tick, so that I needed to correct it after copying to the IDE.I guess you should disable the replacement in your word processor (what should have been 'foo' was something like `foo´).
Well, that's just my argument - maybe I should have phrased it clearer:

I want _less_ details about the server side implementation.
Instead of explaining PHP implementation, IMHO it would be much nicer if the _desired_ response format of requests is shown explicitly (which JSON/XML should be delivered).
PHP examples that show how to produce that response should be treated as an additional bonus for PHP developers, not as an integral part to understand and follow.
Hm, I wrote a plug-in for IntelliJ IDEA that is able to copy code to the clipboard as HTML with correct mime type, so that you can directly copy from IDEA and paste to MS Word or other word processors, see for a Java example.

It uses the style settings configured in the IDE itself (colors and fonts).

Unfortunately it does not yet seem to work with IDEA's PHP plug-in (it fails to include the styles).
If it would be useful to you I can probably enhance my plugin to work with PHP, too and if needed maybe also adjust the HTML to something better suited to the print medium.
Thanks a lot for being so responsive and open.
I hope I did not sound too harsh.

Seems like the two books will be good companions after all.
I'll try to read them in parallel, getting my recipes from "Learning Ext JS" and dive down to "Ext JS in Action" for the deeper understanding.
Currently there are only very few formatting options in File -> Settings -> IDE Setting -> Copy as HTML
Colors and styles are taken from the "Colors & Fonts" section of the general IDEA Editor settings.

However currently the font is fixed to "monospace" with no font-size specified.
I wonder if it makes sense to re-use the font settings from the Colors&Font section, too, or if one would like to be able to override that in the plug-in settings (because the default setting is optimized for screen display and the "Copy as HTML" font size should be optimized for a different context).

What other formatting options would you like to have ? (Padding? Border style?)
It is probably true that the majority of ExtJS users also use PHP, but from my experience Ext JS is quickly growing in other markets, too.
Me myself I am a Java guy and know pretty much nothing about PHP. (Played around with it about ten years ago and only remember that I found it a lot nicer than perl.)

I gave up the introduction very early on. I could probably make myself install PHP and Apache on my machine and re-learn the necessary PHP basics, but why bother when I have several kinds of Java servers running routinely?

I just switched over to "Learning Ext JS" (PACK Publishing) which I also bought and found just the "getting started" info I needed:
First: What js and css files are needed
Then: Pure client side examples
After that: A server call that ought to produce JSON like this and that (plus PHP example code, but only reading the JSON I was able to produce that with my Java setup very quickly).

Comparing the table of contents, "Ext JS in Action" seems more or less like a re-write of "Learning Ext JS".

I might take advantage of up-to-date info about Ext JS 3, but otherwise what's in it?

The most pressing topic for me is developing a theme that is compliant to our style guide/corporate design, but AFAICS neither books has anything substantial to say about that.
Oops, sorry, should have mentioned that.
It's called "Copy as HTML" and it adds a shortcut Ctrl-Shift-A to copy the selected text to the clipboard in a format suitable to paste to Word.There are a few settings in a new settings page.
Let me know if it works for you or how it can be enhanced. It was pretty much a quick hack when I needed that feature for a specific documentation.

Funny you said that about DreamWeaver - from what I heard I always considered it is so much a standard in web development that I always wanted to try it out - but never got around to it.
HI, I just uploaded a new version.
Please try and let me know if it works for you.

I added options to configure the font size and to override the editor's "Show Line Numbers" setting.

I also added options to configure a padding, to convert tabs to spaces and most importantly to "un-indent" the copied text (so that you can copy a snippet that is deeply nested in the block structure without getting unnecessary space on the left).

If you'd like to do me a favor then please through your weight in for better ExtJs support in IDEA, by adding your vote and comment here
or/and in the forum

Wouldn't it be nice to have quick documentation lookup and intelligent code completion for config object properties?
I like that idea of having the server side code available somewhere else.
Printed code is ugly to read anyway - at least if it is not printed with full color syntax highlighting and in landscape paper format (to avoid confusing line wrapping).
Even then I very much prefer the powertools my IDE gives me (quick documentation/api lookup, code navigation, etc.).
Rather than having printed explanations in the book it would be nice if the code were sensibly commented.

Another idea: Maybe invite readers to come up with implementations in different languages (Java, Python, Perl, Ruby, whatever) and host those on the site, too.
I tried and failed to understand this (section 4.1.2 Unifying the Java servlet contexts):

"Begins at the start of the JSF Invoke Application phase and lasts until the
end of the Invoke Application phase on the ensuing JSF postback."

Huh? So _during_ the "Invoke Application" phase there are two page contexts active simultaneously?

Seam's javadoc cleared the issue: Reads are using the old context, writes are using the new one. Sounds strange, but of course has some logic.

Also it have saved me quite some time if the next sentence
"Terminates prematurely if the ensuing request is not a JSF postback."
would be extended with "for example a redirect occurs" or something like that.

For most of our pages/navigation rules there is a <redirect> specified in faces-config.xml.
I'm glad to here that the section has been improved.

Let me say that "Seam in Action" was already invaluable for me.
It finally made me fully understand lots of Seam's concepts.
From the broad introduction to the detailed description of the lifecycle it was full of "aha! effects" for me smilie

> There is no funky double page context read/write paradigm.

Hm, then what about this snippet from the javadoc of org.jboss.seam.contexts.PageContext:
During the INVOKE_APPLICATION phase, set() and remove() manipulate the context of the page that is about to be rendered, while get() returns values from the page that was the source of the request.