Re: Program Flow

But I've always hated (loathed, despised) the idea of an application

configuration file.

I don't enjoy the faces-config.xml file that much either. I believe the
latter versions of JSF use annotations to address these issues.

I'm not certain what they do about the idea of a configuration file and

being able to return a value to determine the next page; in EGL you just
execute a "forward" opcode.

I am guessing they are just hiding the implementation of the Java JSF
annotation.


One other thing that caused me frustration in JSF was wanting to reuse a
screen from two different locations. For instance, if I wanted to go to a
customer search screen from orderentry.jsp and custmaint.jsp. There isn't a
way out of the box that allows me to handoff control to the screen higher in
the "call stack" when the user exits the customer search, and instead I
either need to write my own plumbing or created two different screens.

Aaron Bartell
http://mowyourlawn.com

On Tue, Jun 10, 2008 at 4:44 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
wrote:

Aaron Bartell wrote:

JSF has some nice features for event notification (and redirection) where
you can simply tie a button to a Java method and when clicked it goes

right

to that method. From there the Java programmer has access to globally
defined variables (where I store my state sometimes) and can determine

where

to go next based on the string value returned from the method (i.e.

return

"success" will check the faces config file for a mapping of the literal
"success" to an actual page name like page123.jsp)

It's interesting that you present these together. Personally, I love
the ability to link a button to a method, and absolutely despise the
idea of returning a value which is compared to an XML file to determine
the next page. Me, I'd rather the program was able to determine the
next page directly and forward to it, especially if it needed to add
parms to the URL. In JSP, you do this with
getRequestDispatcher().forward() call and I've always loved that
technique. I mean, if you really want to use a configuration file, then
by all means have a method that accesses the configuration file and
returns a URL and then forward to it. But I've always hated (loathed,
despised) the idea of an application configuration file.

And the EGL folks seems to agree; since they support both the ability to
tie a button to a function and the ability to forward to another page.
I'm not certain what they do about the idea of a configuration file and
being able to return a value to determine the next page; in EGL you just
execute a "forward" opcode. But the button business is even easier.
When you define a function in a page handler, it's visible on the
WYSIWYG editor's Page Data view, and you can then just drag that onto a
button; that binds the button to the function.

Navigation in most of my applications is based on hyperlinks in the page
(for things like drilldowns). You create a table and then link it to a
URL. You add a link attribute to just about anything, and then you can
modify the link to use data from the page. That could be fields, hidden
fields, even columns in a table.

You can do something similar for AJAX requests. You define an area that
is AJAX capable, then you bind an AJAX refresh request to an event (such
as clicking a button or a table cell).

Joe
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.