Re: Using XML in struts

[[EMAIL PROTECTED]]

You Try with  tag
You can access it..

Jay Chandran wrote:
Hi all,
How can i read XML files using struts? is this possible? Can any one provide
a link or give an example for reading XML files using struts?
:-)
Jay


-
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: Re: [OT] Re: Using XML in struts

[sales]

Kindly send all your messages to [EMAIL PROTECTED]  This mail account is not 
functioning anymore. 



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

Re: [OT] Re: Using XML in struts

[Erik Weber]

Thanks. Hope you like them. Nice looking site by the way.
Erik
Vic wrote:
You do need a life.
But... I just bought 2 books from your list.
I keep a track of cool design ideas here: http://sandrasf.com/kiss - 
so if anyone wants to append there they can.

(I like "SQL Tuning", "SQL for smartites" and Doug Lea's book on 
concurency.)
.V



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

Re: [OT] Re: Using XML in struts

[Vic]

You do need a life.
But... I just bought 2 books from your list.
I keep a track of cool design ideas here: http://sandrasf.com/kiss - so 
if anyone wants to append there they can.

(I like "SQL Tuning", "SQL for smartites" and Doug Lea's book on 
concurency.)
.V


Erik Weber wrote:

Joe Germuska wrote:
Also, while I see your point that the overall concept of DOM might 
be more sensible in theory than that of SAX, I found that it's just 
easier to get going with the SAX API than with DOM or even JDOM. You 
can get something working with very few lines of code, and good 
examples are all over the Web. SAX can be a pain to debug though.

Certainly not "more sensible" -- in fact, I've seen over and over 
again people who aren't comfortable with SAX implement things that 
involve reading enormous amounts of XML using DOM and then running 
out of memory.  But they decompose the problem into "first, get 
everything in; then do something to everything" instead of "get one 
in, handle it, and discard it."

I was trying to agree with you. :) But yeah, you're right of course.

I read this awesome book called "Building Parsers in Java" a couple 
years ago

That sounds worth looking up...
These days, so many books are about how to use vendor products or 
APIs. "Mastering" this or that, "Up to Speed" with this or that, and 
the ever popular "Professional" this or that. I'm not knocking those 
-- I need those too of course. But I really appreciate getting my 
hands on those rare books that just focus on the fruits of someone's 
creativity and inventiveness. You may never need to create your own 
language or even build your own regular expression parser, but, do you 
enjoy the art of programming? Do you enjoy math and science? Do you 
like to learn about different ways to approach the same problem? Do 
you like to build a better mousetrap? Dragging and dropping beans and 
jar files is not my idea of a good time. Too bad all any client/tech 
shop seems to want is the same thing someone else already has done, 
with a new marketing twist. Once we have CRUD in a bottle for $19.95 
and all the legacy stuff is snuffed out, what will programmers do for 
a living? Ah, I'm just complaining as usual.

Anyway, of the dozens of Java books I have discovered and/or bought in 
the last few years, a few stand out in the way I described:

* "Building Parsers With Java", by Steven John Metsker, Addison Wesley 
(0-201-71962-2) -- creative, well organized, well written, well 
edited, just a nice piece of work that definitely wasn't "cranked 
out". A fun book about creating and interpreting your own languages.

* "Digital Audio with Java", by Craig A. Lindley, Prentice Hall 
(0-13-087676-3) -- ever wanted to know how to build a parametric EQ in 
Java, from the knobs and LEDs all the way to the wave shaping?

* "Java Design", by Peter Coad (TogetherSoft) and Mark Mayfield, 
Prentice Hall (0-13-981-6) -- offers a perspective on design that 
you probably won't find anywhere else (with chaper titles such as 
"Design with Threads" and "Design with Notification", and hand-drawn 
diagrams); forget that IDE and get out your pad and pencil.

Perhaps funny that I should say this, being a lover of lowest-level 
programming, but I have found that the books that have helped me the 
most as a programmer (in the long run) are ones about design patterns, 
idioms and algorithms (all high-level things in some fashion), rather 
than those about the latest API or product. Unfortunately I cannot 
back up that statement with $$$ earned -- at least not yet. The GoF 
book was published how long ago? How many tech books of today are of 
equal value? I guess it depends on your perspective.

Speaking of perspective, ever read "The Timeless Way of Building"? How 
about (wyy OT) "The Fourth Dimension"?

Man, I need a life. :)
Cheers,
Erik

But I appreciate your elaborating on commons digester. That's the 
one I was thinking of. I'll have to check that out. Also, I've never 
even looked at Spring. By the way, do you happen to know what type 
of parser either of those uses? Just curious.

Digester is a wrapper around SAX.  Digester itself extends 
org.xml.sax.helpers.DefaultHandler   And while the most common way 
people use Digester is to create a tree of objects, once you get 
inside it, you realize that you can do a lot more.  You can write 
Digester rules that do the aforementioned "get one, handle it and 
discard it" as well as the more common rules which do "get one and 
add it to the tree".

Joe


--
RiA-SoA w/JDNC  forums
- help develop a community
My blog 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT] Re: Using XML in struts

[Erik Weber]

Joe Germuska wrote:
Also, while I see your point that the overall concept of DOM might be 
more sensible in theory than that of SAX, I found that it's just 
easier to get going with the SAX API than with DOM or even JDOM. You 
can get something working with very few lines of code, and good 
examples are all over the Web. SAX can be a pain to debug though.

Certainly not "more sensible" -- in fact, I've seen over and over 
again people who aren't comfortable with SAX implement things that 
involve reading enormous amounts of XML using DOM and then running out 
of memory.  But they decompose the problem into "first, get everything 
in; then do something to everything" instead of "get one in, handle 
it, and discard it."

I was trying to agree with you. :) But yeah, you're right of course.

I read this awesome book called "Building Parsers in Java" a couple 
years ago

That sounds worth looking up...
These days, so many books are about how to use vendor products or APIs. 
"Mastering" this or that, "Up to Speed" with this or that, and the ever 
popular "Professional" this or that. I'm not knocking those -- I need 
those too of course. But I really appreciate getting my hands on those 
rare books that just focus on the fruits of someone's creativity and 
inventiveness. You may never need to create your own language or even 
build your own regular expression parser, but, do you enjoy the art of 
programming? Do you enjoy math and science? Do you like to learn about 
different ways to approach the same problem? Do you like to build a 
better mousetrap? Dragging and dropping beans and jar files is not my 
idea of a good time. Too bad all any client/tech shop seems to want is 
the same thing someone else already has done, with a new marketing 
twist. Once we have CRUD in a bottle for $19.95 and all the legacy stuff 
is snuffed out, what will programmers do for a living? Ah, I'm just 
complaining as usual.

Anyway, of the dozens of Java books I have discovered and/or bought in 
the last few years, a few stand out in the way I described:

* "Building Parsers With Java", by Steven John Metsker, Addison Wesley 
(0-201-71962-2) -- creative, well organized, well written, well edited, 
just a nice piece of work that definitely wasn't "cranked out". A fun 
book about creating and interpreting your own languages.

* "Digital Audio with Java", by Craig A. Lindley, Prentice Hall 
(0-13-087676-3) -- ever wanted to know how to build a parametric EQ in 
Java, from the knobs and LEDs all the way to the wave shaping?

* "Java Design", by Peter Coad (TogetherSoft) and Mark Mayfield, 
Prentice Hall (0-13-981-6) -- offers a perspective on design that 
you probably won't find anywhere else (with chaper titles such as 
"Design with Threads" and "Design with Notification", and hand-drawn 
diagrams); forget that IDE and get out your pad and pencil.

Perhaps funny that I should say this, being a lover of lowest-level 
programming, but I have found that the books that have helped me the 
most as a programmer (in the long run) are ones about design patterns, 
idioms and algorithms (all high-level things in some fashion), rather 
than those about the latest API or product. Unfortunately I cannot back 
up that statement with $$$ earned -- at least not yet. The GoF book was 
published how long ago? How many tech books of today are of equal value? 
I guess it depends on your perspective.

Speaking of perspective, ever read "The Timeless Way of Building"? How 
about (wyy OT) "The Fourth Dimension"?

Man, I need a life. :)
Cheers,
Erik

But I appreciate your elaborating on commons digester. That's the one 
I was thinking of. I'll have to check that out. Also, I've never even 
looked at Spring. By the way, do you happen to know what type of 
parser either of those uses? Just curious.

Digester is a wrapper around SAX.  Digester itself extends 
org.xml.sax.helpers.DefaultHandler   And while the most common way 
people use Digester is to create a tree of objects, once you get 
inside it, you realize that you can do a lot more.  You can write 
Digester rules that do the aforementioned "get one, handle it and 
discard it" as well as the more common rules which do "get one and add 
it to the tree".

Joe

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

Re: [OT] Re: Using XML in struts

[Martin Wegner]

+1 on JDOM unless you know upfront that the XML file is going to be big
(greater than a couple of MB).



--- sudip shrestha <[EMAIL PROTECTED]> wrote:

> JDOM: http://www.jdom.org/.
> If you are new to xml-java parsing, then this is the way to go.  When
> I started learning about xml parsing with java a while ago, I
> researched various methods and found that JDOM provides the easiest
> route to get things done.  A quote from JDOM mission: "It behaves like
> Java, it uses Java collections, it is completely natural API for
> current Java developers, and it provides a low-cost entry point for
> using XML".
> 
> 
> On Fri, 14 Jan 2005 10:34:58 -0500, Erik Weber
> <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > Joe Germuska wrote:
> > 
> > > At 8:42 AM -0500 1/14/05, Erik Weber wrote:
> > >
> > >> If you are not familiar with a lot of XML-related APIs, the easiest
> > >> approach is to use the SAX API, in my opinion*.
> > >
> > >
> > > You may be the first person I've ever encountered who finds SAX the
> > > easiest way to process XML!
> > 
> > 
> > Heh. I guess it's because I've written so many SAX event handlers, I
> > feel like I can do it in my sleep now. I probably wrote a few (surely
> > inferior) versions of commons-digester in my time. :) In fact, when I
> > first started doing Web-app programming, I wrote an entire Struts-like
> > framework complete with XML-based validation, similar to commons
> > validator (I knew what Struts was but didn't feel like learning it at
> > the time), as well as app configuration. I started with DOM but ended
> up
> > using SAX for all that as I recall. Lately I've been using pull
> parsers,
> > which are more efficient, but I still think not as dumb as SAX (dumb
> ==
> > good -- I like typing. Makes you feel like you're accomplishing
> > something. Thinking hurts my noggin. :D ). Also, while I see your
> point
> > that the overall concept of DOM might be more sensible in theory than
> > that of SAX, I found that it's just easier to get going with the SAX
> API
> > than with DOM or even JDOM. You can get something working with very
> few
> > lines of code, and good examples are all over the Web. SAX can be a
> pain
> > to debug though.
> > 
> > I read this awesome book called "Building Parsers in Java" a couple
> > years ago (best ASCII-art cover ever) that really inspired me and got
> me
> > thinking along the right lines for using a model like SAX. It's kind
> of
> > like, you have this robot, and you keep handing him parts. The robot
> is
> > smart enough to know which parts to keep and which to ignore (pull is
> > definitely a smarter model than this -- the robot would ask for the
> > parts he wants -- but this is simpler). He keeps a collection of
> > "running" objects -- objects that he has started assembling but hasn't
> > yet finished. Managing the running objects is the only part that
> really
> > involves any thought in coding. Assembly of an object normally starts
> > when an opening element tag is encountered. Assembly continues as
> > sub-elements and attributes are discovered. Once he has finished the
> > object (usually when a matching closing element tag is encountered)
> the
> > robot adds it to the final Collection, Map or complex Object to be
> > returned. To me, it's kinda elegant. But the "deeper" the XML, the
> more
> > difficult it becomes, because there are more running objects at any
> > given time.
> > 
> > But I appreciate your elaborating on commons digester. That's the one
> I
> > was thinking of. I'll have to check that out. Also, I've never even
> > looked at Spring. By the way, do you happen to know what type of
> parser
> > either of those uses? Just curious.
> > 
> > Thanks,
> > Erik
> > 
> > 
> > >
> > >> * There are higher level APIs that might suit you better, depending
> > >> on what you are doing. Struts and Commons Validator use some sort
> of
> > >> higher-level "config" library, if I'm not mistaken, that is
> designed
> > >> for constructing objects/Maps out of config files, so you might
> have
> > >> a look at the source code for one or both of those. I'm sure
> someone
> > >> else could on the list could better inform you about this.
> > >
> > >
> > > This is commons-digester, and it does in fact make it extremely
> simple
> > > to read XML and produce objects from it, especially if you have the
> > > liberty of defining the XML syntax before you write the processing
> > > code.  Digester really helped me get my design oriented towards
> decent
> > > externalization of configuration elements.  I now prefer the Spring
> > > Framework's bean factory, because it standardizes what I normally
> use
> > > Digester for without needing to write even XML processing rules.
> > >
> > > Since I started using Digester (and then Spring), I have not had
> much
> > > cause to deal with XML in the DOM form directly, although I would
> > > think that for most newcomers, the tree model is more
> straightforward
> > > than SAX's event model.  If you do

Re: [OT] Re: Using XML in struts

[sudip shrestha]

JDOM: http://www.jdom.org/.
If you are new to xml-java parsing, then this is the way to go.  When
I started learning about xml parsing with java a while ago, I
researched various methods and found that JDOM provides the easiest
route to get things done.  A quote from JDOM mission: "It behaves like
Java, it uses Java collections, it is completely natural API for
current Java developers, and it provides a low-cost entry point for
using XML".


On Fri, 14 Jan 2005 10:34:58 -0500, Erik Weber <[EMAIL PROTECTED]> wrote:
> 
> 
> Joe Germuska wrote:
> 
> > At 8:42 AM -0500 1/14/05, Erik Weber wrote:
> >
> >> If you are not familiar with a lot of XML-related APIs, the easiest
> >> approach is to use the SAX API, in my opinion*.
> >
> >
> > You may be the first person I've ever encountered who finds SAX the
> > easiest way to process XML!
> 
> 
> Heh. I guess it's because I've written so many SAX event handlers, I
> feel like I can do it in my sleep now. I probably wrote a few (surely
> inferior) versions of commons-digester in my time. :) In fact, when I
> first started doing Web-app programming, I wrote an entire Struts-like
> framework complete with XML-based validation, similar to commons
> validator (I knew what Struts was but didn't feel like learning it at
> the time), as well as app configuration. I started with DOM but ended up
> using SAX for all that as I recall. Lately I've been using pull parsers,
> which are more efficient, but I still think not as dumb as SAX (dumb ==
> good -- I like typing. Makes you feel like you're accomplishing
> something. Thinking hurts my noggin. :D ). Also, while I see your point
> that the overall concept of DOM might be more sensible in theory than
> that of SAX, I found that it's just easier to get going with the SAX API
> than with DOM or even JDOM. You can get something working with very few
> lines of code, and good examples are all over the Web. SAX can be a pain
> to debug though.
> 
> I read this awesome book called "Building Parsers in Java" a couple
> years ago (best ASCII-art cover ever) that really inspired me and got me
> thinking along the right lines for using a model like SAX. It's kind of
> like, you have this robot, and you keep handing him parts. The robot is
> smart enough to know which parts to keep and which to ignore (pull is
> definitely a smarter model than this -- the robot would ask for the
> parts he wants -- but this is simpler). He keeps a collection of
> "running" objects -- objects that he has started assembling but hasn't
> yet finished. Managing the running objects is the only part that really
> involves any thought in coding. Assembly of an object normally starts
> when an opening element tag is encountered. Assembly continues as
> sub-elements and attributes are discovered. Once he has finished the
> object (usually when a matching closing element tag is encountered) the
> robot adds it to the final Collection, Map or complex Object to be
> returned. To me, it's kinda elegant. But the "deeper" the XML, the more
> difficult it becomes, because there are more running objects at any
> given time.
> 
> But I appreciate your elaborating on commons digester. That's the one I
> was thinking of. I'll have to check that out. Also, I've never even
> looked at Spring. By the way, do you happen to know what type of parser
> either of those uses? Just curious.
> 
> Thanks,
> Erik
> 
> 
> >
> >> * There are higher level APIs that might suit you better, depending
> >> on what you are doing. Struts and Commons Validator use some sort of
> >> higher-level "config" library, if I'm not mistaken, that is designed
> >> for constructing objects/Maps out of config files, so you might have
> >> a look at the source code for one or both of those. I'm sure someone
> >> else could on the list could better inform you about this.
> >
> >
> > This is commons-digester, and it does in fact make it extremely simple
> > to read XML and produce objects from it, especially if you have the
> > liberty of defining the XML syntax before you write the processing
> > code.  Digester really helped me get my design oriented towards decent
> > externalization of configuration elements.  I now prefer the Spring
> > Framework's bean factory, because it standardizes what I normally use
> > Digester for without needing to write even XML processing rules.
> >
> > Since I started using Digester (and then Spring), I have not had much
> > cause to deal with XML in the DOM form directly, although I would
> > think that for most newcomers, the tree model is more straightforward
> > than SAX's event model.  If you do need to do something with DOM, it's
> > probably worth checking out dom4j or JDOM, two apis that simplify the
> > DOM and provide a more Java-like API.
> >
> > Joe
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-

Re: [OT] Re: Using XML in struts

[Joe Germuska]

Also, while I see your point that the overall concept of DOM might 
be more sensible in theory than that of SAX, I found that it's just 
easier to get going with the SAX API than with DOM or even JDOM. You 
can get something working with very few lines of code, and good 
examples are all over the Web. SAX can be a pain to debug though.
Certainly not "more sensible" -- in fact, I've seen over and over 
again people who aren't comfortable with SAX implement things that 
involve reading enormous amounts of XML using DOM and then running 
out of memory.  But they decompose the problem into "first, get 
everything in; then do something to everything" instead of "get one 
in, handle it, and discard it."

I read this awesome book called "Building Parsers in Java" a couple years ago
That sounds worth looking up...
But I appreciate your elaborating on commons digester. That's the 
one I was thinking of. I'll have to check that out. Also, I've never 
even looked at Spring. By the way, do you happen to know what type 
of parser either of those uses? Just curious.
Digester is a wrapper around SAX.  Digester itself extends 
org.xml.sax.helpers.DefaultHandler   And while the most common way 
people use Digester is to create a tree of objects, once you get 
inside it, you realize that you can do a lot more.  You can write 
Digester rules that do the aforementioned "get one, handle it and 
discard it" as well as the more common rules which do "get one and 
add it to the tree".

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: [OT] Re: Using XML in struts

[Erik Weber]

Joe Germuska wrote:
At 8:42 AM -0500 1/14/05, Erik Weber wrote:
If you are not familiar with a lot of XML-related APIs, the easiest 
approach is to use the SAX API, in my opinion*.

You may be the first person I've ever encountered who finds SAX the 
easiest way to process XML!

Heh. I guess it's because I've written so many SAX event handlers, I 
feel like I can do it in my sleep now. I probably wrote a few (surely 
inferior) versions of commons-digester in my time. :) In fact, when I 
first started doing Web-app programming, I wrote an entire Struts-like 
framework complete with XML-based validation, similar to commons 
validator (I knew what Struts was but didn't feel like learning it at 
the time), as well as app configuration. I started with DOM but ended up 
using SAX for all that as I recall. Lately I've been using pull parsers, 
which are more efficient, but I still think not as dumb as SAX (dumb == 
good -- I like typing. Makes you feel like you're accomplishing 
something. Thinking hurts my noggin. :D ). Also, while I see your point 
that the overall concept of DOM might be more sensible in theory than 
that of SAX, I found that it's just easier to get going with the SAX API 
than with DOM or even JDOM. You can get something working with very few 
lines of code, and good examples are all over the Web. SAX can be a pain 
to debug though.

I read this awesome book called "Building Parsers in Java" a couple 
years ago (best ASCII-art cover ever) that really inspired me and got me 
thinking along the right lines for using a model like SAX. It's kind of 
like, you have this robot, and you keep handing him parts. The robot is 
smart enough to know which parts to keep and which to ignore (pull is 
definitely a smarter model than this -- the robot would ask for the 
parts he wants -- but this is simpler). He keeps a collection of 
"running" objects -- objects that he has started assembling but hasn't 
yet finished. Managing the running objects is the only part that really 
involves any thought in coding. Assembly of an object normally starts 
when an opening element tag is encountered. Assembly continues as 
sub-elements and attributes are discovered. Once he has finished the 
object (usually when a matching closing element tag is encountered) the 
robot adds it to the final Collection, Map or complex Object to be 
returned. To me, it's kinda elegant. But the "deeper" the XML, the more 
difficult it becomes, because there are more running objects at any 
given time.

But I appreciate your elaborating on commons digester. That's the one I 
was thinking of. I'll have to check that out. Also, I've never even 
looked at Spring. By the way, do you happen to know what type of parser 
either of those uses? Just curious.

Thanks,
Erik


* There are higher level APIs that might suit you better, depending 
on what you are doing. Struts and Commons Validator use some sort of 
higher-level "config" library, if I'm not mistaken, that is designed 
for constructing objects/Maps out of config files, so you might have 
a look at the source code for one or both of those. I'm sure someone 
else could on the list could better inform you about this.

This is commons-digester, and it does in fact make it extremely simple 
to read XML and produce objects from it, especially if you have the 
liberty of defining the XML syntax before you write the processing 
code.  Digester really helped me get my design oriented towards decent 
externalization of configuration elements.  I now prefer the Spring 
Framework's bean factory, because it standardizes what I normally use 
Digester for without needing to write even XML processing rules.

Since I started using Digester (and then Spring), I have not had much 
cause to deal with XML in the DOM form directly, although I would 
think that for most newcomers, the tree model is more straightforward 
than SAX's event model.  If you do need to do something with DOM, it's 
probably worth checking out dom4j or JDOM, two apis that simplify the 
DOM and provide a more Java-like API.

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

RE: Using XML in struts

[Slattery, Tim - BLS]

> How can i read XML files using struts? is this possible? Can 
> any one provide a link or give an example for reading XML 
> files using struts?


If you're talking about reading an XML file in your Java code, check out
Jakarta Commons Digester: http://jakarta.apache.org/commons/digester/

--
Tim Slattery
[EMAIL PROTECTED]


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

[OT] Re: Using XML in struts

[Joe Germuska]

At 8:42 AM -0500 1/14/05, Erik Weber wrote:
If you are not familiar with a lot of XML-related APIs, the easiest 
approach is to use the SAX API, in my opinion*.
You may be the first person I've ever encountered who finds SAX the 
easiest way to process XML!

* There are higher level APIs that might suit you better, depending 
on what you are doing. Struts and Commons Validator use some sort of 
higher-level "config" library, if I'm not mistaken, that is designed 
for constructing objects/Maps out of config files, so you might have 
a look at the source code for one or both of those. I'm sure someone 
else could on the list could better inform you about this.
This is commons-digester, and it does in fact make it extremely 
simple to read XML and produce objects from it, especially if you 
have the liberty of defining the XML syntax before you write the 
processing code.  Digester really helped me get my design oriented 
towards decent externalization of configuration elements.  I now 
prefer the Spring Framework's bean factory, because it standardizes 
what I normally use Digester for without needing to write even XML 
processing rules.

Since I started using Digester (and then Spring), I have not had much 
cause to deal with XML in the DOM form directly, although I would 
think that for most newcomers, the tree model is more straightforward 
than SAX's event model.  If you do need to do something with DOM, 
it's probably worth checking out dom4j or JDOM, two apis that 
simplify the DOM and provide a more Java-like API.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: Using XML in struts

[Erik Weber]

If you are not familiar with a lot of XML-related APIs, the easiest 
approach is to use the SAX API, in my opinion*.

1) Write a SAX event handler (receives events when XML elements are 
opened, closed, and when text values of attributes and elements are 
encountered -- you assemble your objects as the events arrive)
2) Configure a SAXParserFactory
3) Use the factory to create a SAXParser
4) Register your event handler with the parser
5) Create an input source from your XML file and connect it to the parser
6) Tell the parser to parse

This is a streaming-style "push" technique -- you read the file from 
start to finish, caching whatever you are interested in. If you need 
random access (to be able to read in forward and reverse) to the file, 
take a look at DOM -- which is used for loading and holding an entire 
document in memory. I've never found a use for it.

Another technique that is used, for example, in Jabber packet handling 
libraries, is pull parsing. Pull parsing is similar to push parsing 
except (to be very basic here) you can tell the parser to seek the part 
of the document you are interested in, rather than handle a bunch of 
events you aren't interested in.

* There are higher level APIs that might suit you better, depending on 
what you are doing. Struts and Commons Validator use some sort of 
higher-level "config" library, if I'm not mistaken, that is designed for 
constructing objects/Maps out of config files, so you might have a look 
at the source code for one or both of those. I'm sure someone else could 
on the list could better inform you about this.

Erik

[EMAIL PROTECTED] wrote:
Struts does not have a specific support for XML, but you can use inside a
webapp all the libraries that you normally use under classic applications.
For example, if you want to load a DOM for an XML file inside an action
(not very elegant...), you can use DOM4J (or similar libraries).
If you want to use XML files inside JSP pages you can use the xtags, and
so on.
Ciao
Antonio Petrelli
 

Hi all,
How can i read XML files using struts? is this possible? Can any one
   

provide
 

a link or give an example for reading XML files using struts?
:-)
Jay


   


-
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: Using XML in struts

[brenmcguire]

Struts does not have a specific support for XML, but you can use inside a
webapp all the libraries that you normally use under classic applications.
For example, if you want to load a DOM for an XML file inside an action
(not very elegant...), you can use DOM4J (or similar libraries).
If you want to use XML files inside JSP pages you can use the xtags, and
so on.
Ciao
Antonio Petrelli

> Hi all,
>
> How can i read XML files using struts? is this possible? Can any one
provide
> a link or give an example for reading XML files using struts?
>
> :-)
>
>
> Jay
>
>
>
>
>
>


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

Using XML in struts

[Jay Chandran]

Hi all,

How can i read XML files using struts? is this possible? Can any one provide
a link or give an example for reading XML files using struts?

:-)


Jay






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