users
[Top] [All Lists]

Re: [cinjug-users] Splitting tiles-config.xml (Struts)

To: <users@xxxxxxxxxx>
Subject: Re: [cinjug-users] Splitting tiles-config.xml (Struts)
From: "Edward Sumerfield" <esumerfd@xxxxxxxxxxx>
Date: Fri, 28 Jan 2005 12:03:59 -0500
Delivered-to: mailing list users@cinjug.org
Mailing-list: contact users-help@cinjug.org; run by ezmlm
References: <7266759DD1C5D6428963975E00FA084309AC66@csg-ml02.cardinalsolutions.com>
This was our first approach and worked for SunOneWebServer because its deployment technique resulted in a predictable path. WebLogic does not offer this reliability. We were deploying to a cluster of servers and WebLogic deploys each under a directory that maps to the node name. This results in a different pathing location on each machine. If porting off JBoss is not a concern then neither is this one.

----- Original Message ----- From: "Ted Tollefson" <ttollefson@xxxxxxxxxxxxxxxxxxxxx>
To: <users@xxxxxxxxxx>
Sent: Friday, January 28, 2005 11:01 AM
Subject: RE: [cinjug-users] Splitting tiles-config.xml (Struts)



The ugly solution:

In your build process, do an XSL transform on the XML that does nothing. The result will be an XML file containing everything. Deploy this file with your project.

Pros
- You can better organize large XML config files into smaller files and sub-directories
- No absolute paths needed
- Simple to setup


Cons
- When changing the XML file, one must always remember to make changes in the smaller file (even though there is a complete tiles-config.xml in the normal location).


This worked well for my project once it was built into the Ant script.

Regards,
Ted

________________________________

From: Amol Deshmukh [mailto:adeshmukh@xxxxxxxxxxxxxx]
Sent: Fri 1/28/2005 10:28 AM
To: 'users@xxxxxxxxxx'
Subject: [cinjug-users] Splitting tiles-config.xml (Struts)



*** WARNING: XML question ***
*** WARNING: Long post ***

Hi,

I was exploring ways to organize tiles-config.xml
into multiple smaller files. The simple approach I
am taking (well... trying to) is to have one main
file and use XML entity references to the smaller
parts.

So that I have one main tiles-config as:
 tiles-config-main.xml

which defines my "super-definitions" from which my
other <definition>s "extend".

The actual definitions are put in multiple files
(sort of based on modules, but we are not using
struts modules).

So that I have files like:
 tiles-config-a.xmlf
 tiles-config-b.xmlf

which I amd trying to include in the main file as:
-------------------------------------------------------
<!DOCTYPE tiles-definitions PUBLIC
 "-//Apache Software Foundation//DTD Tiles Configuration//EN"
 "http://struts.apache.org/dtds/tiles-config_1_1.dtd";
[
 <!ENTITY a-config SYSTEM "tiles-config-a.xmlf" >
 <!ENTITY b-config SYSTEM "tiles-config-b.xmlf" >

]>
<tiles-definitions>
<!-- super definitions go here -->
.
.
<!-- 'import' definitions from fractional xml files
     that have series of <definition> tags
-->
&a-config;
&b-config;
</tiles-definitions>
-------------------------------------------------------

The problem I am having is getting JBoss3.2 to resolve
the entity reference at startup without having to give
and absolute file path. With the path specified as above,
JBoss tries to look for
 "d:\jboss-3.2.6\bin\tiles-config-a.xmlf"
  ^^^^^^^^^^^^^^__ my JBOSS_HOME directory

Clearly, the part that needs to change is the ENTITY
declaration, but I have tried few possiblities and it
just doesnt seem to work.

Other ways I have tried to so far:
 <!ENTITY a-config     SYSTEM "file:tiles-config-a.xmlf" >
&
 <!ENTITY a-config     SYSTEM "tiles-config-a.xmlf" NDATA tiles-a >

Any ideas/suggestions? How do others organize large
tiles-config.xml files?

Thanks,
~ amol

---------
You may unsubscribe from this mailing list
by sending a blank email addressed to:
users-unsubscribe@xxxxxxxxxx

--
Find additional help by sending a blank email
addressed to:
users-help@xxxxxxxxxx






--------------------------------------------------------------------------------


---------
You may unsubscribe from this mailing list
by sending a blank email addressed to:
users-unsubscribe@xxxxxxxxxx

--
Find additional help by sending a blank email
addressed to:
users-help@xxxxxxxxxx


<Prev in Thread] Current Thread [Next in Thread>