date:20030613

cvs commit: jakarta-struts/src/share/org/apache/struts/tiles/doc-files tilesUML.gif

2003-06-13 Thread rleland

rleland 2003/06/13 23:20:56

Modified:src/share/org/apache/struts/tiles package.html
Added: src/share/org/apache/struts/tiles/doc-files tilesUML.gif
Log:
Add UML for tiles package,
restore package.html to previous verson

Revision ChangesPath
1.9 +320 -3jakarta-struts/src/share/org/apache/struts/tiles/package.html

Index: package.html
===
RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/package.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- package.html 14 Jun 2003 06:10:34 - 1.8
+++ package.html 14 Jun 2003 06:20:56 - 1.9
@@ -1,5 +1,322 @@
+
+
+Tiles Package
+

-The "tiles" package allows the definition of reusable components.
-
-
+
+The Tiles taglib and framework allows building web pages by assembling reusable
+pieces of pages, called Tiles. A Tiles is usually a simple JSP page.
+
+
+
+Introduction
+The Tiles framework allows building pages by assembling reusable Tiles.
+ As an example, the page in the next figure can be build by assembling a
+ header, a footer, a menu and a body.
+
+Each Tiles (header, menu, body, ...) is a JSP page and can itself be build
+ by assembling other Tiles.
+Using Tiles can be compared as using Java methods: You need to define the Tiles
(the method body), and then you can "call" this body anywhere you want, passing it
some parameters. In Tiles, parameters are called "attributes" in order to avoid
confusion with the request parameters.
+The Tiles body can be a simple JSP page, a Struts action or any URI pointing
+ to a resource inside the current web site.
+Inserting the body, or calling it, is done with the tag anywhere in a JSP page. Insertion can also be done by specifying
+ a definition name as the path of a Struts forward or as input,
+ forward or include attributes of a Struts action.
+Tiles bodies are used to create layouts, reusable parts, ... Tiles
insertions
+ are used to insert Tiles. The same Tiles can be reused several times in
+ the same site, or even in the same page.
+Insertion of a Tiles body can be associated to a logical name in what Tiles
calls a "definition". A definition contains a logical name, a page used as body and
some attribute values. The definition declaration doesn't insert the associated Tiles
body. It just associates it with the name. A definition name can be used anywhere
insertion of a Tiles body can occur. The associated Tiles body is then inserted with
associated attributes.
+The definition declarations can be done in JSP pages or in one or more
+ centralized files. A definition can extend another one, overload some
attributes,
+ add new attributes ... This allows the declaration of a "master" definition
+ declaring the common layout, header, menu and footer. All other definitions
+ extend this master layout thereby making it possible to change the entire
+ site look & feel simply by changing the master definition.
+
+
+Simple Examples
+
+ Insert a JSP page
+
+
+This example inserts the specified page in place of the tag. The page attribute
is any valid URL pointing to a resource inside the current site.
+
+
+Insert a Tiles passing some attributes
+
+
+
+
+
+
+
+
+
+ This example inserts the specified page, passing it the attributes.
Attributes
+are stored in a Tiles context which is passed to the inserted pag and
+can then be accesssed by their names.
+
+
+Retrieve an attribute value as String
+
+
+
+This example retrieves the value of the attribute "title" and prints it as a
String in the current output stream. The method toString() is applied on the attribute
value, allowing to pass any kind of object as value.
+
+
+Insert Tiles referenced by an attribute
+
+
+
+ This inserts the Tiles referenced by the attribute "menu" value. The
+specified attribute value is first retrieved from current Tiles's context,
+and then the value is used as a page target to insert.
+
+
+Classic Layout
+ This example is a layout assembling a page in the classic
header-footer-menu-body
+fashion.
+

cvs commit: jakarta-struts/src/share/org/apache/struts/tiles package.html

2003-06-13 Thread rleland

rleland 2003/06/13 23:10:34

Modified:src/share/org/apache/struts/tiles package.html
Log:
Add UML for tiles package

Revision ChangesPath
1.8 +3 -321jakarta-struts/src/share/org/apache/struts/tiles/package.html

Index: package.html
===
RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/package.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- package.html 23 Apr 2003 00:42:33 - 1.7
+++ package.html 14 Jun 2003 06:10:34 - 1.8
@@ -1,323 +1,5 @@
-
-
-Tiles Package
-

-
-The Tiles taglib and framework allows building web pages by assembling reusable
-pieces of pages, called Tiles. A Tiles is usually a simple JSP page.
-
-Introduction
-The Tiles framework allows building pages by assembling reusable Tiles.
- As an example, the page in the next figure can be build by assembling a
- header, a footer, a menu and a body.
-
-Each Tiles (header, menu, body, ...) is a JSP page and can itself be build
- by assembling other Tiles.
-Using Tiles can be compared as using Java methods: You need to define the Tiles
(the method body), and then you can "call" this body anywhere you want, passing it
some parameters. In Tiles, parameters are called "attributes" in order to avoid
confusion with the request parameters.
-The Tiles body can be a simple JSP page, a Struts action or any URI pointing
- to a resource inside the current web site.
-Inserting the body, or calling it, is done with the tag anywhere in a JSP page. Insertion can also be done by specifying
- a definition name as the path of a Struts forward or as input,
- forward or include attributes of a Struts action.
-Tiles bodies are used to create layouts, reusable parts, ... Tiles
insertions
- are used to insert Tiles. The same Tiles can be reused several times in
- the same site, or even in the same page.
-Insertion of a Tiles body can be associated to a logical name in what Tiles
calls a "definition". A definition contains a logical name, a page used as body and
some attribute values. The definition declaration doesn't insert the associated Tiles
body. It just associates it with the name. A definition name can be used anywhere
insertion of a Tiles body can occur. The associated Tiles body is then inserted with
associated attributes.
-The definition declarations can be done in JSP pages or in one or more
- centralized files. A definition can extend another one, overload some
attributes,
- add new attributes ... This allows the declaration of a "master" definition
- declaring the common layout, header, menu and footer. All other definitions
- extend this master layout thereby making it possible to change the entire
- site look & feel simply by changing the master definition.
-
-
-Simple Examples
-
- Insert a JSP page
-
-
-This example inserts the specified page in place of the tag. The page attribute
is any valid URL pointing to a resource inside the current site.
-
-
-Insert a Tiles passing some attributes
-
-
-
-
-
-
-
-
-
- This example inserts the specified page, passing it the attributes.
Attributes
-are stored in a Tiles context which is passed to the inserted pag and
-can then be accesssed by their names.
-
-
-Retrieve an attribute value as String
-
-
-
-This example retrieves the value of the attribute "title" and prints it as a
String in the current output stream. The method toString() is applied on the attribute
value, allowing to pass any kind of object as value.
-
-
-Insert Tiles referenced by an attribute
-
-
-
- This inserts the Tiles referenced by the attribute "menu" value. The
-specified attribute value is first retrieved from current Tiles's context,
-and then the value is used as a page target to insert.
-
-
-Classic Layout
- This example is a layout assembling a page in the classic
header-footer-menu-body
-fashion.
-
-<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>
-
-
-

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/tiles package.html

2003-06-13 Thread rleland

rleland 2003/06/13 22:50:39

  Modified:src/share/org/apache/struts/taglib/tiles package.html
  Log:
  Correct Spelling
  
  Revision  ChangesPath
  1.2   +2 -2  
jakarta-struts/src/share/org/apache/struts/taglib/tiles/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/tiles/package.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- package.html  14 Jun 2003 05:43:28 -  1.1
  +++ package.html  14 Jun 2003 05:50:39 -  1.2
  @@ -6,8 +6,8 @@

  
   
  - The "struts-ttiles" tag library contains tags that are useful in
  -creating dynamic  reusable components. 
  + The "struts-tiles" tag library contains tags that are useful in
  +creating dynamic reusable components. 
   

   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/tiles/doc-files tilesUML.gif

2003-06-13 Thread rleland

rleland 2003/06/13 22:43:28

  Added:   src/share/org/apache/struts/taglib/tiles package.html
   src/share/org/apache/struts/taglib/tiles/doc-files
tilesUML.gif
  Log:
  Add UML for Tiles taglib
  
  Revision  ChangesPath
  1.1  
jakarta-struts/src/share/org/apache/struts/taglib/tiles/package.html
  
  Index: package.html
  ===
  
  
  
Package Documentation for org.apache.struts.taglib.tiles Package
  
   
 
  
   The "struts-ttiles" tag library contains tags that are useful in
  creating dynamic  reusable components. 
  
   
  
  
  
  
  1.1  
jakarta-struts/src/share/org/apache/struts/taglib/tiles/doc-files/tilesUML.gif
  
<>
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/tiles/doc-files - New directory

2003-06-13 Thread rleland

rleland 2003/06/13 22:15:47

  jakarta-struts/src/share/org/apache/struts/taglib/tiles/doc-files - New directory

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/template/doc-files template.gif templateUML.jpg

2003-06-13 Thread rleland

rleland 2003/06/13 22:08:19

  Modified:src/share/org/apache/struts/taglib/template package.html
  Added:   src/share/org/apache/struts/taglib/template/doc-files
template.gif
  Removed: src/share/org/apache/struts/taglib/template/doc-files
templateUML.jpg
  Log:
  Update UML and replace jpg with smaller gif
  
  Revision  ChangesPath
  1.5   +1 -1  
jakarta-struts/src/share/org/apache/struts/taglib/template/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/template/package.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- package.html  29 Oct 2002 05:31:39 -  1.4
  +++ package.html  14 Jun 2003 05:08:19 -  1.5
  @@ -60,7 +60,7 @@
   
 
 
  -
  +
 

   
  
  
  
  1.1  
jakarta-struts/src/share/org/apache/struts/taglib/template/doc-files/template.gif
  
<>
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/nested/logic/doc-files nested-logic.gif nested-logic.jpg

2003-06-13 Thread rleland

rleland 2003/06/13 22:00:18

  Modified:src/share/org/apache/struts/taglib/nested/logic package.html
  Added:   src/share/org/apache/struts/taglib/nested/logic/doc-files
nested-logic.gif
  Removed: src/share/org/apache/struts/taglib/nested/logic/doc-files
nested-logic.jpg
  Log:
  Update UML and replace jpg with smaller gif
  
  Revision  ChangesPath
  1.2   +1 -1  
jakarta-struts/src/share/org/apache/struts/taglib/nested/logic/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/nested/logic/package.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- package.html  30 Mar 2002 02:15:52 -  1.1
  +++ package.html  14 Jun 2003 05:00:17 -  1.2
  @@ -11,7 +11,7 @@
logic of   the logic tags don't change, except in that all references to 
   beans and  bean properties will be managed in a nested context. 
   
  -
  +
   
   
   
  
  
  
  1.1  
jakarta-struts/src/share/org/apache/struts/taglib/nested/logic/doc-files/nested-logic.gif
  
<>
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/nested/html/doc-files nested-html.gif nested-html.jpg

2003-06-13 Thread rleland

rleland 2003/06/13 21:31:44

  Modified:src/share/org/apache/struts/taglib/nested/html package.html
  Added:   src/share/org/apache/struts/taglib/nested/html/doc-files
nested-html.gif
  Removed: src/share/org/apache/struts/taglib/nested/html/doc-files
nested-html.jpg
  Log:
  Update UML and replace jpg with smaller gif
  
  Revision  ChangesPath
  1.2   +1 -1  
jakarta-struts/src/share/org/apache/struts/taglib/nested/html/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/nested/html/package.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- package.html  30 Mar 2002 02:15:52 -  1.1
  +++ package.html  14 Jun 2003 04:31:43 -  1.2
  @@ -10,7 +10,7 @@
   logic of   the html tags don't change, except in that all references to beans
   and  bean properties will be managed in a nested context. 
   
  -
  +
   
   
   
  
  
  
  1.1  
jakarta-struts/src/share/org/apache/struts/taglib/nested/html/doc-files/nested-html.gif
  
<>
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/nested/bean/doc-files nested-bean.gif nested-bean.jpg

2003-06-13 Thread rleland

rleland 2003/06/13 21:24:48

  Modified:src/share/org/apache/struts/taglib/nested/bean package.html
  Added:   src/share/org/apache/struts/taglib/nested/bean/doc-files
nested-bean.gif
  Removed: src/share/org/apache/struts/taglib/nested/bean/doc-files
nested-bean.jpg
  Log:
  Update UML and replace jpg with smaller gif
  
  Revision  ChangesPath
  1.2   +1 -1  
jakarta-struts/src/share/org/apache/struts/taglib/nested/bean/package.html
  
  Index: package.html
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/nested/bean/package.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- package.html  30 Mar 2002 02:17:24 -  1.1
  +++ package.html  14 Jun 2003 04:24:48 -  1.2
  @@ -10,7 +10,7 @@
   except in that all references to  beans and  bean properties will be managed 
   in a nested context. 

  - 
  + 



  
  
  
  1.1  
jakarta-struts/src/share/org/apache/struts/taglib/nested/bean/doc-files/nested-bean.gif
  
<>
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Question on struts, tiles and jsf

2003-06-13 Thread Craig R. McClanahan

I think the concept of extending TilesRequestProcessor (and/or integrating
Tiles support into the standard request processor) makes a lot of sense
for this ... it would be nice to be able to use Tiles together with JSF.
I also want to look at making it possible to use the Validator framework
with JSF components as well, as was suggested at the BOF on JavaServer
Faces.  Taken together, these would be a powerful
reason to continue to use Struts underneath a Faces-based app.

Enhancement requests for this library can go the same place as bug
reports:

  http://nagoya.apache.org/bugzilla/

Craig

On Tue, 10 Jun 2003, Ives Landrieu wrote:

> Date: Tue, 10 Jun 2003 20:55:53 +0200
> From: Ives Landrieu <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Question on struts, tiles and jsf
>
> Hi,
>
> I was experimenting with struts and tiles (not very experienced in using
> them yet) and wanted to explore whether these could be combined with
> Java Server Faces (using struts-faces). This does not seem to be
> possible, as both the struts-faces integration library as tiles depend
> on using their own request processor class.
> As far as I can tell from a quick look at the struts sources (I don't
> think the source code for struts-faces is available?), the main reasons
> why this is done is to initialize (reading their config files etc.) and
> intercept some forwards/requests.
> I think this functionality should all be done in the plugin class (or
> some kind of listener interface should be created to intercept
> forwards). If I understand correctly, plugins are exactly meant for
> initializing other application components. I think that the interception
> of forwards should also be delegated to plugins (or refactored out of
> the request processor).
>  I understand that the way things are is for historical reasons because
> tiles was integrated with struts relatively recently, but it seems that
> in order to achieve maximum flexibility for struts, the plugin interface
> should become more advanced, so that special purpose request processors
> become unnecessary.
> So, to end with a question, am I correct in my analysis? Or is there
> another way to combine tiles with java server faces? Can I file this
> somewhere as a RFE?
>
> Ives
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Struts can't "get its act together" - JavaPro

2003-06-13 Thread Don Brown

Rumor has it IDEA is working on a C# version :)

Don

On Fri, 13 Jun 2003, David Graham wrote:

> >the .NET heads ( is there a term used to describe them? ) come back and say
> >that it is easier and faster to build in C# then Java. They say that the
> >tools to work with C# are better ( I don't agree ).
>
> Having worked with VS.NET and various Java IDEs I can say that .NET
> developers don't know what they're missing.  They might have easy gui
> construction but VS is woefully lacking in ease of use and features (the
> most noticeable to me is the lack of automated refactorings).
>
> David
>
>
> >In fairness, we should
> >not assume that .NET developers are going to skip design or write GUIs with
> >no functionality. We should look at the total cost of development.
> >
> >I must take issue with your point that
> >  "It's this complexity that goes begging when UI construction is the sole
> >(or even majority) measure of productivity."
> >
> >The fact is that as of right now you can build and maintain a GUI using
> >.NET
> >faster and easier (read productivity). You can build rich and complex
> >functionality using C#. The building the business functionality is
> >basically
> >on par between Java and C#. Is it not fair to say that the productivity
> >gained in the GUI construction is a clear win for .NET?
> >
> >If you take two groups one for Java/Struts/et. al. and one for .NET, where
> >they are equally proficient in their respective technologies, and give them
> >the same application to build, which will be done first? Bottom line who
> >gets the job done first? The business world has decided that the .NET team
> >will be done first. From what I have seen myself I have little reason to
> >doubt this.
> >
> >I have made the argument about how much richer Java is as a language, and
> >what I hear back is that the difference between Java and C# is like the
> >difference between Coke and Pepsi. Again, perception is reality.
> >
> >Good tools do have a direct impact on development schedules. When are we
> >going to have JSF and the tools to support it? Are the anti-Microsquish
> >league (IBM, SUN, Oracle, et. al.) going to come up with tools to match
> >.NET?
> >
> >Lastly, one of our teams here is writing a .NET front-end talking to Web
> >Services supplied by a Java J2EE middle tier. The say they are having their
> >cake and are able to eat it too. The interesting thing is they are
> >succeeding and are getting their applications to the users faster and
> >management has noticed.
> >
> >Glenn
> >
> >
> >-Original Message-
> >From: Chris Gerrard [mailto:[EMAIL PROTECTED]
> >Sent: Friday, June 13, 2003 1:48 PM
> >To: Struts Developers List
> >Subject: RE: Struts can't "get its act together" - JavaPro
> >
> >
> >Glenn,
> >
> >I'm continuously unimpressed by the implicit assumption that "Developer
> >Productivity" == "GUI construction". The blind acceptance of this hoary old
> >chestnut has been a huge impediment to real progress in developing better
> >systems.
> >
> >Given that the rapid construction of a UI is a good thing, what's my beef?
> >
> >Simply put, there's a whole world of complexity behind the UI that needs to
> >be conceived of, designed, and implemented before the application is
> >useful. It's this complexity that goes begging when UI construction is the
> >sole (or even majority) measure of productivity.
> >
> >There are levels of productivity. GUI building is on the surface, easy to
> >see. But it's thin, and not nourishing. Real productivity lies in the
> >ability to provide rich, complex functionality that supports real people in
> >getting real things done.
> >
> >GUI tools tend to concentrate on the thin layer on top, providing some
> >hardwired mechanism(s) underneath to support the UI. This is an extreme
> >limitation in real productivity in that it limits the access the developers
> >have to the underlying bits. Struts provides the framework that lets us
> >deal with the UI and get past it into the Java world where we're really
> >limited only by our own skills and knowledge.
> >
> >Like Vic said in his post, I provide training in Struts (and other stuff)
> >to corporate clients. I recently mentored a bunch of mainframe programmers
> >starting up with Java/Struts in order to reimplement their existing FoxPro
> >application. It's a simple customer info collection application - get some
> >info into a form, save it, find it, update it, save the changes. The UI
> >side of things is straightforward with Struts, as it would be with other
> >technologies. BUT, real complexity lies unspoken in the "find it"
> >functionality.
> >
> >The naive approach is to provide a single-field input form accepting a
> >client ID# which is used to look up the info. Next up is the "search form"
> >approach: "Let's give them a form that looks like the input form, let them
> >fill in some value(s) and then search for their info". OK, now we're
> >talking. What fields are on the form? How do the val

RE: Struts can't "get its act together" - JavaPro

2003-06-13 Thread David Graham

the .NET heads ( is there a term used to describe them? ) come back and say
that it is easier and faster to build in C# then Java. They say that the
tools to work with C# are better ( I don't agree ).
Having worked with VS.NET and various Java IDEs I can say that .NET 
developers don't know what they're missing.  They might have easy gui 
construction but VS is woefully lacking in ease of use and features (the 
most noticeable to me is the lack of automated refactorings).

David


In fairness, we should
not assume that .NET developers are going to skip design or write GUIs with
no functionality. We should look at the total cost of development.
I must take issue with your point that
 "It's this complexity that goes begging when UI construction is the sole
(or even majority) measure of productivity."
The fact is that as of right now you can build and maintain a GUI using 
.NET
faster and easier (read productivity). You can build rich and complex
functionality using C#. The building the business functionality is 
basically
on par between Java and C#. Is it not fair to say that the productivity
gained in the GUI construction is a clear win for .NET?

If you take two groups one for Java/Struts/et. al. and one for .NET, where
they are equally proficient in their respective technologies, and give them
the same application to build, which will be done first? Bottom line who
gets the job done first? The business world has decided that the .NET team
will be done first. From what I have seen myself I have little reason to
doubt this.
I have made the argument about how much richer Java is as a language, and
what I hear back is that the difference between Java and C# is like the
difference between Coke and Pepsi. Again, perception is reality.
Good tools do have a direct impact on development schedules. When are we
going to have JSF and the tools to support it? Are the anti-Microsquish
league (IBM, SUN, Oracle, et. al.) going to come up with tools to match
.NET?
Lastly, one of our teams here is writing a .NET front-end talking to Web
Services supplied by a Java J2EE middle tier. The say they are having their
cake and are able to eat it too. The interesting thing is they are
succeeding and are getting their applications to the users faster and
management has noticed.
Glenn

-Original Message-
From: Chris Gerrard [mailto:[EMAIL PROTECTED]
Sent: Friday, June 13, 2003 1:48 PM
To: Struts Developers List
Subject: RE: Struts can't "get its act together" - JavaPro
Glenn,

I'm continuously unimpressed by the implicit assumption that "Developer
Productivity" == "GUI construction". The blind acceptance of this hoary old
chestnut has been a huge impediment to real progress in developing better
systems.
Given that the rapid construction of a UI is a good thing, what's my beef?

Simply put, there's a whole world of complexity behind the UI that needs to
be conceived of, designed, and implemented before the application is
useful. It's this complexity that goes begging when UI construction is the
sole (or even majority) measure of productivity.
There are levels of productivity. GUI building is on the surface, easy to
see. But it's thin, and not nourishing. Real productivity lies in the
ability to provide rich, complex functionality that supports real people in
getting real things done.
GUI tools tend to concentrate on the thin layer on top, providing some
hardwired mechanism(s) underneath to support the UI. This is an extreme
limitation in real productivity in that it limits the access the developers
have to the underlying bits. Struts provides the framework that lets us
deal with the UI and get past it into the Java world where we're really
limited only by our own skills and knowledge.
Like Vic said in his post, I provide training in Struts (and other stuff)
to corporate clients. I recently mentored a bunch of mainframe programmers
starting up with Java/Struts in order to reimplement their existing FoxPro
application. It's a simple customer info collection application - get some
info into a form, save it, find it, update it, save the changes. The UI
side of things is straightforward with Struts, as it would be with other
technologies. BUT, real complexity lies unspoken in the "find it"
functionality.
The naive approach is to provide a single-field input form accepting a
client ID# which is used to look up the info. Next up is the "search form"
approach: "Let's give them a form that looks like the input form, let them
fill in some value(s) and then search for their info". OK, now we're
talking. What fields are on the form? How do the values entered interact
with one another - implicit ANDs or ORs, or do we try to give them a real
query builder? And so it goes. Even better, as the user population gains
experience with the application, having a flexible powerful language and
platform underneath employed via strong, supple frameworks and
architectures makes it much, much easier to continually improve things than
is the case for sy

Re: Struts can't "get its act together" - JavaPro

2003-06-13 Thread Vic Cekvenich

When will JSF have a tool: I think the answer is 2004, but this is the 
wrong list for this.

Is there something in .NET that can do this like there are dozens of 
tools for Struts:
http://www.scioworks.com/scioworks_camino.html

I also just started using an open source bean generator that writes 
Struts bean getters and DAO.

I would say that Java has little advantage over C#.
Business managers would prefer .NET.
J2EE has mislead application developers in the past, Ex: EJB, which lead 
lots of bus. users to .NET.

I would hope that people do not use JSF as best J2EE has to offer. I 
think the best J2EE has to offer is Open Source tools like Struts.
Ex:
http://news.netcraft.com
This shows how much more MS is popular than Sun.
But it also shows how much more popular OS is than MS.

So my argument has been that MS > Sun, but Open SSource > MS.

I say that Struts + JSTL + IBatis + OO Programer can code circles around 
best .NET combo. I am willing to prove it any day or night, even via the 
web.

Then lets talk cost to operate:
MS tends to be cheaper than Sun. But... OS is cheaper to operate than MS.
Same for support. I go seach struts mail list: "validate date" and it 
shows like 1200 times people asked this question.
So I say... past is the future. OS > MS > Sun

Please do not put forth JSF as "best" of J2EE, it might be best Sun has 
(like they have iPlannet, NetBeans, SlowLaris, should I go on?).

I "sell" consulting; and clients feel better when of the bat I say, yes, 
.NET is better than Sun.
Then I sell Open Source. They say you can save us money?
YES! I say.
How popular is this?
http://news.netcraft.com I say.
Oh. they say.

Now I have offense.
I say: let me show you how quick I can write an 2 screen master detail 
app., with  a nice UI.
Ren *.HTML to JSP.
Write actions to go to JSP!
Add tiles/menu.
Demo one. Est time. 5 minutes for 2 screens.
I say, can your graphic artis using Dream Weaver customize this? Yes, 
they say, they like their logo bigger, and they like colors!
(At this time, client thinks I am done - I did not do beans yet, they do 
not know what beans is or why we need it)
I say: How would you like not to have to get legal approval and no buget 
meetings! Maybe get a little raise instead.
Then I say, ok, lets make some reusable comonents (beans) that could get 
used by Soap, Flash, and elsewhere in the app and test in your app with 
data.
DAO, 5 minutes, they like stored procedures usualy. (Last time they saw 
a DAO, it was EJB and... they say, wow, Java got better.)
Beans (I have getter/setter macro) 5 minutes.
Show Unit test of beans talking DAO !
I explain Soap, Flash compoents, and their web app. and ask for a PO and 
sit there while they glance at each other!

Do they want to talk iReport.sf.net. Great, they have a wizzard. Stress 
test? Disel Test! Demo? no, they have seen enough.
What is your pain I ask?  How many screens can your developers do per 
day? Do you want me to teach them a few OO tricks?

So I never argue #C vs Java. I absorb the punch and allways agree with 
client and agree that they should use popular tools that save money 
for the org.

Good luck selling! But.. if you ask more Sun JSF questions, there is JSF 
mail list on the Sun site.

.V

Davidson, Glenn wrote:
Chris, 
Thanks for your response, I find many of your arguments and others
compelling. Please note that I am working with Struts when I had the
opportunity to work with .NET. (Just what does that say about me? :-) )I
agree with the majority of what you wrote and probably didn't fully
understand the parts I might have issue with. 

The issue here is the perception by the majority of the business world. I
will be using many of the issues raised here to try and to get more
acceptance for Struts/JSP If you need any proof of the business
acceptance of .NET just look at the job sites for web developers and see how
many listings are for .NET and how many are for Struts/JSP etc.
I have used the argument that 

"Real productivity lies in the ability to provide rich, complex
functionality that supports real people in getting real things done."
the .NET heads ( is there a term used to describe them? ) come back and say
that it is easier and faster to build in C# then Java. They say that the
tools to work with C# are better ( I don't agree ). In fairness, we should
not assume that .NET developers are going to skip design or write GUIs with
no functionality. We should look at the total cost of development.
I must take issue with your point that
 "It's this complexity that goes begging when UI construction is the sole
(or even majority) measure of productivity."
The fact is that as of right now you can build and maintain a GUI using .NET
faster and easier (read productivity). You can build rich and complex
functionality using C#. The building the business functionality is basically
on par between Java and C#. Is it not fair to say that the productivity
gained in the GUI construction is a clear win for .NET?

RE: Struts can't "get its act together" - JavaPro

2003-06-13 Thread Chris Gerrard

Glenn,

comments inline 

At 03:26 PM 6/13/2003, you wrote:
Chris,
Thanks for your response, I find many of your arguments and others
compelling. Please note that I am working with Struts when I had the
opportunity to work with .NET. (Just what does that say about me? :-) )I
agree with the majority of what you wrote and probably didn't fully
understand the parts I might have issue with.
The issue here is the perception by the majority of the business world.
I agree, and am dismayed that "the business world has been so artfully 
misled

 I will be using many of the issues raised here to try and to get more
acceptance for Struts/JSP If you need any proof of the business
acceptance of .NET just look at the job sites for web developers and see how
many listings are for .NET and how many are for Struts/JSP etc.
It's a shame that the advertising for "web developers" can be used as 
a measure of the need for people who conceive, architect, design, and 
develop "real" systems. The "Web" component of any business-central system 
is only the top or outer-most layer.

I have used the argument that

"Real productivity lies in the ability to provide rich, complex
functionality that supports real people in getting real things done."
the .NET heads ( is there a term used to describe them? ) come back and say
that it is easier and faster to build in C# then Java. They say that the
tools to work with C# are better ( I don't agree ). In fairness, we should
not assume that .NET developers are going to skip design or write GUIs with
no functionality. We should look at the total cost of development.
Agreed. And the total cost of development "BEGINS" with the inital 
rendering of a UI, and extends forward into time for the whole life of the 
project/system. The initail ease of rendering the UI is vastly overwhelmed 
by the lifetime costs of the system.


I must take issue with your point that
 "It's this complexity that goes begging when UI construction is the sole
(or even majority) measure of productivity."
The fact is that as of right now you can build and maintain a GUI using .NET
faster and easier (read productivity). You can build rich and complex
functionality using C#. The building the business functionality is basically
on par between Java and C#. Is it not fair to say that the productivity
gained in the GUI construction is a clear win for .NET?
Mixing and matching. Is it indeed a fact that building & maintaining a 
GUI using .NET is faster and easier? How about it Vic? Is architecting a 
Struts application using Actions as atomic business operations wired 
together with the I/O via struts-config employing configurable forwards to 
customize logic flow on a par with .NET? (I don't know, and don't know 
anyone else who really does, either)


If you take two groups one for Java/Struts/et. al. and one for .NET, where
they are equally proficient in their respective technologies, and give them
the same application to build, which will be done first? Bottom line who
gets the job done first? The business world has decided that the .NET team
will be done first. From what I have seen myself I have little reason to
doubt this.
When IS "done". First deployment? First adjustment? Last enhancement? 
Abandonment? I enjoy being pedantic ;-), and have worked on too many 
business systems to buy into the "done when first seen" line. And is "the 
business world" the same clods who bet everybody's farm on the webification 
of everything? My experience with corporate clients is that serious 
businesses are beginning to invest again in getting their people involved 
with the technology that will enable them to provide the best value, now 
and going into the future. And that's Java. Good for now. Good for later. 
Robust, mature technology. Competition in the marketplace. Assured 
functionality via widely supported standards without onerous locked in 
licensing fees.


I have made the argument about how much richer Java is as a language, and
what I hear back is that the difference between Java and C# is like the
difference between Coke and Pepsi. Again, perception is reality.
So we need to publish, promulgate, provoke, persuade, and otherwise 
p-verb until we alter the "perception"


Good tools do have a direct impact on development schedules. When are we
going to have JSF and the tools to support it? Are the anti-Microsquish
league (IBM, SUN, Oracle, et. al.) going to come up with tools to match
.NET?
The only tools lacking in this analysis, it seems, are the GUI tools, 
and I hope the answer is "yes".


Lastly, one of our teams here is writing a .NET front-end talking to Web
Services supplied by a Java J2EE middle tier. The say they are having their
cake and are able to eat it too. The interesting thing is they are
succeeding and are getting their applications to the users faster and
management has noticed.
The server side functionality of their app is Java? Yea! That's a GOOD 
thing.


Glenn

One last emphasis - Struts is a wonderful

RE: Struts can't "get its act together" - JavaPro

2003-06-13 Thread Davidson, Glenn

Chris, 
Thanks for your response, I find many of your arguments and others
compelling. Please note that I am working with Struts when I had the
opportunity to work with .NET. (Just what does that say about me? :-) )I
agree with the majority of what you wrote and probably didn't fully
understand the parts I might have issue with. 

The issue here is the perception by the majority of the business world. I
will be using many of the issues raised here to try and to get more
acceptance for Struts/JSP If you need any proof of the business
acceptance of .NET just look at the job sites for web developers and see how
many listings are for .NET and how many are for Struts/JSP etc.

I have used the argument that 

"Real productivity lies in the ability to provide rich, complex
functionality that supports real people in getting real things done."

the .NET heads ( is there a term used to describe them? ) come back and say
that it is easier and faster to build in C# then Java. They say that the
tools to work with C# are better ( I don't agree ). In fairness, we should
not assume that .NET developers are going to skip design or write GUIs with
no functionality. We should look at the total cost of development.

I must take issue with your point that
 "It's this complexity that goes begging when UI construction is the sole
(or even majority) measure of productivity."

The fact is that as of right now you can build and maintain a GUI using .NET
faster and easier (read productivity). You can build rich and complex
functionality using C#. The building the business functionality is basically
on par between Java and C#. Is it not fair to say that the productivity
gained in the GUI construction is a clear win for .NET?

If you take two groups one for Java/Struts/et. al. and one for .NET, where
they are equally proficient in their respective technologies, and give them
the same application to build, which will be done first? Bottom line who
gets the job done first? The business world has decided that the .NET team
will be done first. From what I have seen myself I have little reason to
doubt this. 

I have made the argument about how much richer Java is as a language, and
what I hear back is that the difference between Java and C# is like the
difference between Coke and Pepsi. Again, perception is reality.

Good tools do have a direct impact on development schedules. When are we
going to have JSF and the tools to support it? Are the anti-Microsquish
league (IBM, SUN, Oracle, et. al.) going to come up with tools to match
.NET? 

Lastly, one of our teams here is writing a .NET front-end talking to Web
Services supplied by a Java J2EE middle tier. The say they are having their
cake and are able to eat it too. The interesting thing is they are
succeeding and are getting their applications to the users faster and
management has noticed.

Glenn


-Original Message-
From: Chris Gerrard [mailto:[EMAIL PROTECTED]
Sent: Friday, June 13, 2003 1:48 PM
To: Struts Developers List
Subject: RE: Struts can't "get its act together" - JavaPro


Glenn,

I'm continuously unimpressed by the implicit assumption that "Developer 
Productivity" == "GUI construction". The blind acceptance of this hoary old 
chestnut has been a huge impediment to real progress in developing better 
systems.

Given that the rapid construction of a UI is a good thing, what's my beef?

Simply put, there's a whole world of complexity behind the UI that needs to 
be conceived of, designed, and implemented before the application is 
useful. It's this complexity that goes begging when UI construction is the 
sole (or even majority) measure of productivity.

There are levels of productivity. GUI building is on the surface, easy to 
see. But it's thin, and not nourishing. Real productivity lies in the 
ability to provide rich, complex functionality that supports real people in 
getting real things done.

GUI tools tend to concentrate on the thin layer on top, providing some 
hardwired mechanism(s) underneath to support the UI. This is an extreme 
limitation in real productivity in that it limits the access the developers 
have to the underlying bits. Struts provides the framework that lets us 
deal with the UI and get past it into the Java world where we're really 
limited only by our own skills and knowledge.

Like Vic said in his post, I provide training in Struts (and other stuff) 
to corporate clients. I recently mentored a bunch of mainframe programmers 
starting up with Java/Struts in order to reimplement their existing FoxPro 
application. It's a simple customer info collection application - get some 
info into a form, save it, find it, update it, save the changes. The UI 
side of things is straightforward with Struts, as it would be with other 
technologies. BUT, real complexity lies unspoken in the "find it" 
functionality.

The naive approach is to provide a single-field input form accepting a 
client ID# which is used to look up the info. Next up is the "sear

37 matches

Mail list logo