RE: html:options /

2002-10-24 Thread Couball, James 
Why not have your singleton hold a reference to the bean object that carries
the data?

This is a classic case of any problem in computer science can be solved
with an additional layer of abstraction.

James.

 -Original Message-
 From: Roland Carlsson [mailto:roland.c;swetravel.se]
 Sent: Thursday, October 24, 2002 5:12 AM
 To: Struts Users Mailing List
 Subject: Re: html:options /
 
 I found whats wrong... my bean aren't a bean... since a bean have to have
 a
 public no argument constructor and my is a Singleton... so I'll guess that
 I
 have to live with a little ugliness in the view.
 
 %
   request.setAttribute(parts,
 demo.DBApplication.getInstance().getAllParts());
 %
 
 Thanks for the fun and the help
 
 Regards
 Roland
 
 - Original Message -
 From: deepak [EMAIL PROTECTED]
 To: Struts Users Mailing List [EMAIL PROTECTED]
 Sent: Thursday, October 24, 2002 1:51 PM
 Subject: Re: html:options /
 
 
  Yes you can.
 
  for e.g.
 
  bean:define id=carriers name=CarrierForm property=carrierVector/
 
  - Original Message -
  From: Roland Carlsson [EMAIL PROTECTED]
  To: Struts Users Mailing List [EMAIL PROTECTED]
  Sent: Thursday, October 24, 2002 5:04 PM
  Subject: Re: html:options /
 
 
   Can't carriers be a collection that I can get from the ActionForm?
  
   Regards
   Roland Carlsson
  
   - Original Message -
   From: [EMAIL PROTECTED]
   To: Struts Users Mailing List [EMAIL PROTECTED]
   Sent: Thursday, October 24, 2002 1:11 PM
   Subject: Re: html:options /
  
  
   
html:select property=carrier  %-- The form's property to be
populated --%
  html:options collection=carriers property=id
 labelProperty
=name/
/html:select
   
carriers is a list of Carrier objects in my Session Context
   
   
   
   
   
  Roland
  CarlssonTo:  Struts
 Users
   Mailing List [EMAIL PROTECTED]
  roland.c@swetra cc:
  vel.se  Subject:
 html:options
 /
   
  24/10/2002 01:04
  PM
  Please respond
  to Struts Users
  Mailing List
  
   
   
   
   
   
   
Hello!
I'm trying to use html:options/ but the only thing I get get into
the list
are Object.toString() values witch is not very useful for the user.
   
What I like to do is the equal to
   
option value=%= myObj.getId() %%= myObj.getName() %/option
   
Can this be done?
   
Thanks in advance
Roland Carlsson
   
   
--
To unsubscribe, e-mail:   
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: 
mailto:struts-user-help;jakarta.apache.org
   
   
   
   
   
   
--
To unsubscribe, e-mail:
   mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
   mailto:struts-user-help;jakarta.apache.org
   
  
  
   --
   To unsubscribe, e-mail:
  mailto:struts-user-unsubscribe;jakarta.apache.org
   For additional commands, e-mail:
  mailto:struts-user-help;jakarta.apache.org
 
 
  --
  To unsubscribe, e-mail:
 mailto:struts-user-unsubscribe;jakarta.apache.org
  For additional commands, e-mail:
 mailto:struts-user-help;jakarta.apache.org
 
 
 
 --
 To unsubscribe, e-mail:   mailto:struts-user-
 [EMAIL PROTECTED]
 For additional commands, e-mail: mailto:struts-user-
 [EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org

RE: DAO or ... ?

2002-10-14 Thread Couball, James 

I recommend taking a look at the Session Façade pattern in the Java Blue
Prints.  No matter if you use EJBs or not, this pattern encapsulates the
ideas that Simon was mentioning.  

Does anyone know the name of the more general pattern that doesn't involve
Session Beans specifically?

One of my general concerns is design to test.  I like to be able to test
the (business/persistence) layer that the actions will call independently of
struts, actions, etc.  Encapsulating that layer in an API (or wrapping with
a session bean) makes this possible.  

Sincerely,
James. 

 -Original Message-
 From: Andrew Hill [mailto:[EMAIL PROTECTED]]
 Sent: Monday, October 14, 2002 8:16 AM
 To: Struts Users Mailing List
 Subject: RE: DAO or ... ?
 
 But you still call the API from the action right - is this not invoking
 the
 functionality that persists your data?
 
 Seems a bit like semantic juggling to me... (after all the persistance
 layer
 is just an abstraction API on top of writing to db/disk/punchcard
 itself...)
 ;-)
 
 I would however agree that there ought to be some sort of abstracting
 layer
 between the view and the implementation specific details of the p-tier...
 
 -Original Message-
 From: Chappell, Simon P [mailto:[EMAIL PROTECTED]]
 Sent: Monday, October 14, 2002 23:04
 To: Struts Users Mailing List; [EMAIL PROTECTED]
 Subject: RE: DAO or ... ?
 
 
 You invoke your persistence code in the same place that you would invoke
 any
 other code ... not in the Action!
 
 Write all your core application code (business rules, persistence,
 communications etc) in a way that has no connection to the view portion of
 your system and then create a API to it. This way you can have any client
 you like call into your core code and your core code doesn't need to worry
 about what calls it, only about acting upon requests.
 
 Then use the actions to call into the API and pass the API return values
 to
 the JSPs. Works great.
 
 /--\/---\   /\
 |Client|-- |API|--|Core|
 |Code  ||   |   |Code|
 \--/\---/   \/
 
 The API is now your fire break. Nothing on the Core Code side has to worry
 about displaying anything and nothing in the Client Code has to worry
 about
 calculating anything.
 
 Simon
 
 -
 Simon P. Chappell [EMAIL PROTECTED]
 Java Programming Specialist  www.landsend.com
 Lands' End, Inc.   (608) 935-4526
 
 
 -Original Message-
 From: Andrew Hill [mailto:[EMAIL PROTECTED]]
 Sent: Monday, October 14, 2002 9:57 AM
 To: Struts Users Mailing List
 Subject: RE: DAO or ... ?
 
 
 So where should one invoke the persistance layer?
 
 -Original Message-
 From: Lacerda, Wellington (AFIS) [mailto:[EMAIL PROTECTED]]
 Sent: Monday, October 14, 2002 22:51
 To: 'Struts Users Mailing List'
 Subject: RE: DAO or ... ?
 Importance: High
 
 
 Hi Kevin
 
 Avoid persistence in Action code as much as you can.
 
 This is the general recommendation.
 
 Wellington Silva
 Author of JSP and Tag Libraries for Web Development
 FAO of the UN - Consultant
 
 -Original Message-
 From: Kevin Viet [mailto:[EMAIL PROTECTED]]
 Sent: Monday, October 14, 2002 4:45 PM
 To: struts-user
 Subject: DAO or ... ?
 
 
 My question is a web app design question.
 What pattern you guys follow when you want to save a domain object in
 the database ?:
 
 - use the DAO pattern of java blueprint  (persistence layer is called
 into classes)
 - call to persistence statements into action code :
 
  // store example
  try {
  PeristenceLayer pl = getPerstitenceLayer();
  pl.save(domainObject);
  }
  catch (Exception
 
 
 --
 Kevin Viet [EMAIL PROTECTED]
 ActiVia Networks
 
 
 
 
 --
 To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 
 
 --
 To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 
 
 --
 To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 
 
 --
 To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 
 
 --
 To unsubscribe, e-mail:   mailto:struts-user-
 [EMAIL PROTECTED]
 For additional commands, e-mail: mailto:struts-user-
 [EMAIL PROTECTED]

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

RE: DAO or ... ?

2002-10-14 Thread Couball, James 

That was it, the Command pattern was what I was thinking of... but Session
Façade had a bit more to it.

Thanks for the info.

James.

 -Original Message-
 From: Jamie M [mailto:[EMAIL PROTECTED]]
 Sent: Monday, October 14, 2002 10:37 AM
 To: Struts Users Mailing List
 Subject: RE: DAO or ... ?
 
 How about the Command Pattern:
 
 http://www.javaworld.com/javaworld/javatips/jw-javatip68.html
 
 An EJB version is mentioned in 'EJB Design Patterns'
 (http://www2.theserverside.com/books/EJBDesignPatterns/index.jsp)
 too.
 
 jamie
 
 --- Couball, James [EMAIL PROTECTED]
 wrote:
  I recommend taking a look at the Session Façade
  pattern in the Java Blue
  Prints.  No matter if you use EJBs or not, this
  pattern encapsulates the
  ideas that Simon was mentioning.
 
  Does anyone know the name of the more general
  pattern that doesn't involve
  Session Beans specifically?
 
  One of my general concerns is design to test.  I
  like to be able to test
  the (business/persistence) layer that the actions
  will call independently of
  struts, actions, etc.  Encapsulating that layer in
  an API (or wrapping with
  a session bean) makes this possible.
 
  Sincerely,
  James.
 
   -Original Message-
   From: Andrew Hill
  [mailto:[EMAIL PROTECTED]]
   Sent: Monday, October 14, 2002 8:16 AM
   To: Struts Users Mailing List
   Subject: RE: DAO or ... ?
  
   But you still call the API from the action right -
  is this not invoking
   the
   functionality that persists your data?
  
   Seems a bit like semantic juggling to me... (after
  all the persistance
   layer
   is just an abstraction API on top of writing to
  db/disk/punchcard
   itself...)
   ;-)
  
   I would however agree that there ought to be some
  sort of abstracting
   layer
   between the view and the implementation specific
  details of the p-tier...
  
   -Original Message-
   From: Chappell, Simon P
  [mailto:[EMAIL PROTECTED]]
   Sent: Monday, October 14, 2002 23:04
   To: Struts Users Mailing List;
  [EMAIL PROTECTED]
   Subject: RE: DAO or ... ?
  
  
   You invoke your persistence code in the same place
  that you would invoke
   any
   other code ... not in the Action!
  
   Write all your core application code (business
  rules, persistence,
   communications etc) in a way that has no
  connection to the view portion of
   your system and then create a API to it. This way
  you can have any client
   you like call into your core code and your core
  code doesn't need to worry
   about what calls it, only about acting upon
  requests.
  
   Then use the actions to call into the API and pass
  the API return values
   to
   the JSPs. Works great.
  
   /--\/---\   /\
   |Client|-- |API|--|Core|
   |Code  ||   |   |Code|
   \--/\---/   \/
  
   The API is now your fire break. Nothing on the
  Core Code side has to worry
   about displaying anything and nothing in the
  Client Code has to worry
   about
   calculating anything.
  
   Simon
  
  
 
 -
   Simon P. Chappell
  [EMAIL PROTECTED]
   Java Programming Specialist
  www.landsend.com
   Lands' End, Inc.
  (608) 935-4526
  
  
   -Original Message-
   From: Andrew Hill
  [mailto:[EMAIL PROTECTED]]
   Sent: Monday, October 14, 2002 9:57 AM
   To: Struts Users Mailing List
   Subject: RE: DAO or ... ?
   
   
   So where should one invoke the persistance layer?
   
   -Original Message-
   From: Lacerda, Wellington (AFIS)
  [mailto:[EMAIL PROTECTED]]
   Sent: Monday, October 14, 2002 22:51
   To: 'Struts Users Mailing List'
   Subject: RE: DAO or ... ?
   Importance: High
   
   
   Hi Kevin
   
   Avoid persistence in Action code as much as you
  can.
   
   This is the general recommendation.
   
   Wellington Silva
   Author of JSP and Tag Libraries for Web
  Development
   FAO of the UN - Consultant
   
   -Original Message-
   From: Kevin Viet [mailto:[EMAIL PROTECTED]]
   Sent: Monday, October 14, 2002 4:45 PM
   To: struts-user
   Subject: DAO or ... ?
   
   
   My question is a web app design question.
   What pattern you guys follow when you want to
  save a domain object in
   the database ?:
   
   - use the DAO pattern of java blueprint
  (persistence layer is called
   into classes)
   - call to persistence statements into action code
  :
   
// store example
try {
PeristenceLayer pl = getPerstitenceLayer();
pl.save(domainObject);
}
catch (Exception
   
   
   --
   Kevin Viet [EMAIL PROTECTED]
   ActiVia Networks
   
   
   
   
   --
   To unsubscribe, e-mail:
  
  mailto:[EMAIL PROTECTED]
   For additional commands, e-mail:
   mailto:[EMAIL PROTECTED]
   
   
   --
   To unsubscribe, e-mail:
  
  mailto:[EMAIL PROTECTED]
   For additional commands, e-mail:
   mailto:[EMAIL PROTECTED]
   
   
   --
   To unsubscribe, e-mail:
  
  mailto:[EMAIL PROTECTED]
   For additional commands, e-mail:
   mailto

RE: logClassName problem under JDK 1.4 (nightly build)

2002-03-21 Thread Couball, James 

Frank,

The class Jdk14Logger can be found in the nightly build jakarta-commons
logging project.  You can get this jar at:

http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-logging/

Hope this helps.

Sincerely,
James.


-Original Message-
From: Lawlor, Frank [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, March 21, 2002 12:12 PM
To: 'Struts (E-mail)'
Subject: logClassName problem under JDK 1.4 (nightly build)

I'm using a struts nightly build (1/2/02) and it uses
the commons-*.jar files.  Before upgrading to JDK 1.4
the console would say something like:

logClassName=NoOpLog

Now it says

logClassName=org.apache.commons.logging.impl.Jdk14Logger

and in the localhost_log I get:

org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
java.lang.ClassNotFoundException:
org.apache.commons.logging.impl.Jdk14Logger
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.ja
va:464)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.ja
va:273)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:338)
at org.apache.commons.digester.Digester.init(Digester.java:309)
at
org.apache.struts.action.ActionServlet.initDigester(ActionServlet.java:1576)
   ...

There is no Jdk14Logger in the commons-logging jar.

What do I need to do to fix this?
Where can I set the logger class (how)?

Frank Lawlor
Athens Group, Inc.
(512) 345-0600 x151
Athens Group, an employee-owned consulting firm integrating technology
strategy and software solutions.



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

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

RE: EJB = bad = MS.net

2002-02-20 Thread Couball, James 

Depends on the project requirements.

Transactions across multiple data sources being a big one.
Large and scalable being another.

...what are the others?

Although his words say something different, maybe Vic is arguing that MS
does this better/easier/cheaper than J2EE -- not that J2EE is fundamentally
bad. 

James.

-Original Message-
From: Pu Huang [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, February 20, 2002 11:37 AM
To: 'Struts Users Mailing List'
Subject: RE: EJB = bad = MS.net

Depends on the project size.


-Original Message-
From: Thompson, Darryl [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 20, 2002 2:28 PM
To: Struts Users Mailing List
Subject: RE: EJB = bad = MS.net


 I STRONGLY disagree with this statement. We have been doing EJBs for 2 yrs
at my shop. Our Order Entry system  uses EJBs to capture customer orders in
36 cities (US) in every US timezone and we have had nothing but success. By
the way there is NO reason to buy BEA weblogic unless you are running EJBs
and don't trust JBOSS (which I do). Tomcat is much better at serving
webpages the WLS or Websphere, EJBs are one of the cornerstones of J2EE,
wake up Vic...

 -Original Message-
 From: Vic Cekvenich [SMTP:[EMAIL PROTECTED]]
 Sent: Wednesday, February 20, 2002 11:42 AM
 To:   Struts Users Mailing List
 Cc:   [EMAIL PROTECTED]
 Subject:  EJB = bad = MS.net
 
 Home page of Jakarta has this
 http://jakarta.apache.org/site/news.html#0130.2
 on this:
 http://www.mail-archive.com/general%40jakarta.apache.org/msg03376.html
 
 I agree. Doing EJBs is bad on many levels and creates more problems. 
 Avoid EJB if you want to stay in Java.
 
 Alternative is to just use Struts + TomCat + RowSet (or DAO if you are 
 doing something simple or small) and done. This is the sweet spot. MVC 
 is all you need.
 
 Alternative, do EJBs and your organization WILL switch to MS .NET on the 
 next project, leave J2EE, and you have to learn VB.net.
 
 EJBs are for newbies. (If you need middleware (very rare) use SOAP)
 
 lol,
 Vic
 
 
 
 --
 To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]

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

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

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

Struts vs Cocoon

2002-02-13 Thread Couball, James 

I am planning on a prototype application that uses MVC.  I plan on using
XML/XSLT to implement the view layer.  I am pretty well versed with struts
by now but not with Cocoon 2.x.  At first blush Cocoon looks like Struts
with XML/XSLT capabilities.

 

Is this more or less correct?

 

Sincerely,

James.

Extending Struts (was: Boost Struts with XSLT and XML - JavaWorld.com)

2002-02-04 Thread Couball, James 

I have been lurking for a couple of months now and have seen many useful
extensions to the Struts framework.  I am curious to understand what thought
has gone into better understand how Struts can be extended in common ways
such that:

(1) Extensions are an add-on/plug-in rather than a rewrite of the Struts
classes.

And

(2) non-overlapping extensions are compatible.  For example, wouldn't expect
Velocity and XSLT extensions to work together but might expect different
classes of extensions to work together.

Can the types of extensions be classified?  For example, the XSLT extension
talked about in the JavaWorld article could be a View extension.

Should the framework be separated out into core and extension pieces?
For example, maybe the custom taglibs should be considered part of the JSP
Extension.  And the JSP Extension considered a View extension that follows
certain rules that other View extensions (such as Velocity and XSLT) must
follow.

Thank you,
James.





-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]] 
Sent: Monday, February 04, 2002 9:51 AM
To: Struts Users Mailing List
Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com


Vaughan Jackson wrote:
 
 A couple of naive questions.
 
 1. Given that the authors of the article mention that the
Cocoon framework uses XML and XSLT to generate HTML
(among other formats), I assume their motivation
for using Struts is to gain the MVC framework. Is this
correct? Does Velocity also have the same deficiency
compared with Struts?


It's said that Velocity enforces MVC better than JSPs.



 2. Is there any possibility that something like this
may become a formal extension to Struts?

Definately. 



-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

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

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

Process in a struts project

2002-01-29 Thread Couball, James 

Hello,
 
Please excuse this slightly off topic message, but I felt that this
discussion could be valuable to the group.  Please ignore if you find it too
OT.  I don't mind suggestions for other forums for this question.
 
My questions are listed at the end of this email, the rest is background.
 
We utilize struts on a number of projects.  As a user of struts, I am trying
to come up with a good process for developing web apps that helps us manage
the hand-offs between:
(1) Graphic designers (responsible for branding, look and feel, color
schemes, etc.),
(2) Front-end engineers (responsible for realizing the UI using the graphic
designers' guidelines), 
(3) Back-end engineers (know struts, java, J2EE, etc.)
 
In our current process, the graphics designers design the branding, look and
feel, and other graphic elements that make up the user interface.  From this
HTML templates are created for the different types of pages in our site.
The front-end engineers then take the page templates and the site map and
create the pages for the entire site.  At this point, we have static HTML
pages with hard coded 'place holder' values.
 
The 'static site' is then passed on to the back-end engineers.  They fill in
the dynamic portion of the pages: populating data and other content.
 
I have a couple of problems with this:
(1) The back-end engineers have to know a lot about HTML.  Often they have
to make minor tweeks in the HTML that breaks the page for one browser or
another.  I don't think they should have to know all this.
(2) Once the front-end engineers hand off the pages, they consider
themselves done and out of the loop.  Global look and feel changes become
very hard to do because the front-end engineers no longer recognize the
pages.
(3) No matter how hard I try, system engineers _still_ put in java code in
the JSP pages.
 

I would like to come up with a solution where:
(1) The front-end engineers to deliver pages that have been unit tested with
test data (not hard coded HTML).
(2) The front-end engineers own or are responsible for the pages through the
lifetime of the system.

 
Ok, the first step is to train our front-end engineers to use JSP and our
custom tags (struts and otherwise). 
 
The second step is to enable the front-end engineers to be able to unit test
each page under a variety of different data inputs.  That would require a
number of things:
(1) First, the data the page makes use of needs to be well defined.  This
would make the job of interfacing between the front-end engineers and the
back-end engineers easier.  However, I don't think there is any standard way
of doing this and no way at all of doing this within the JSP page.
(2) The front-end engineer needs to know how to create the holders for the
data to be rendered within the page.  Using struts, this would involve
writing java beans or ActionForm beans.  (How are these beans configuration
managed along with the JSP they apply to?)
(3) The front-end engineer needs to compile and deploy the JSP.
(4) The front-end engineer needs a test harness that helps/supports building
data objects, storing them in the appropriate scope (page, request, session,
...), and then forwarding to the page to be tested.
 
Using XML/XSLT makes some of these steps easier because there is a well
defined way to define the model, the front-end engineer does not need to
create java beans, and the test harness is easier to setup because there are
no data beans to populate.
 
My questions are:
(1) Does it sound reasonable for front-end engineers to know how to do?
(2) Are there tools that support this activity?
(3) Could a servlet (or some other test harness) be written to help the
front-end engineer unit test their pages?
(4) Is unit testing page rendering something that is automated or
eye-balled?
 
Any comments will be appreciated.
 
Sincerely,
James Couball