RE: XMLC Include Files

Hi Jake,

> Doesn't this sort of defeat the purpose of using SSI's in the
> first place?  If you have a bunch of .html mockup files which
> reference the same markup, but don't use ssi's directly, rather
> you do the <!-- start foo.ssi --> stuff, then you are just
> repeating this information in all your .html files where you
> could have put that info in .ssi files in the first place and
> just then glob copy all your .html files to .shtml files to work
> with IIS or Apache.  Maybe I'm missing something?

I think you are.

We want to be able to edit the markup in one place (ie. the html files). For
our purposes, we group the markup based on sections of an app. For instance,
code pertaining to Contract screns is all stored in A_Contracts.html. Now
this actually contains markup "snippets" for the Contract intro, list,
maint, and configuration screens - and each of these screens gets split out
into its own .ssi file.

As a developer/designer, I most frequently just view A_Contracts.html
directly in a browser in order to see what things look like. But lets say I
want to show the system to mgmt or non-technical types in order for them to
validate the design/layout. Well, they need to see the mockup view. For that
you need something that can process .shtml files (remember, we haven't even
compiled to XMLC yet). This is what IIS/Apache in conjunction with .shtml
files is for. So continuing with the example I gave above, we define

Contracts.shtml
ContractList.shtml
ContractMaint.shtml
ContractOptions.shtml
etc.

Each of these looks something like this: (using ContractsList.shtml as an
example)

<!--#include file="page_start.ssi"-->

<table summary="" cellspacing="0" cellpadding="0" height="100%" width="100%"
class="layout">
<tr><td class="page_top">
  <!--#include file="title_logged_in.ssi"-->
  <!--#include file="header_logged_in.ssi"-->
</td></tr>
<tr><td class="page_body">
  <!--#include file="contract_list.ssi"-->
</td></tr>
<tr><td class="page_bottom">
  <!--#include file="footer.ssi"-->
</td></tr>
</table>

<!--#include file="page_end.ssi"-->

See how this builds the complete view? It sucks in the headers, footers,
menu bars, etc. And its all instantly "previewable" through a simple web
browser (no java or xmlc code is needed to create a working demo of the
webapp...I can "log into" the app, navigate around, etc). Management loves
this functionality because they can review early before any programming is
done (thus catching many design errors before you actually spend developer
dollars coding them).

Now each of these .shtml files actually corresponds to an actual webapp
screen, so we want to compile these into XMLC objects. We also want to
perform text replacements, however, changing relative links into event
references and stuff like that. So for that we use the CopyAndReplace
functionality - this copies the files from our mockups directory into our
XMLC source directory, resolving .ssi refences and performing text
replacement as well.

From there, we let XMLC compile it into objects which we then use in the
code.

> Additionally, all this begs the question of the usefulness of the
> GenerateSSI taskdef and CopyReplace taskdef since, isn't this
> functionality already provided by the XMLC compiler anyway?  Why
> duplicate this with separate taskdefs?

Because we don't intend to use XMLC forever. I think a better question is to
say "why do something in XMLC that can be done just as easily in Ant?". In
other words, what are you going to do as soon as you have some non-XMLC DOM
source? At that point, you're going to have to replicate whatever
"additional" functionality you were relying on in XMLC. For us, it won't be
an issue. The ONLY thing we are using XMLC for is to get a reference to the
DOM and for rendering those DOMs. That's it.

Not sure if that makes sense or not, but that's the rationale. It was
developed over the past year and a half precisely because we couldn't get
XMLC to do exactly what we wanted. We use this approach in multiple projects
and it has proven very very functional, so I can't really imagine a reason
why we _wouldn't_ do it this way.

Christian
----------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jacob Kjome
> Sent: Monday, June 23, 2003 11:26 AM
> To: [email protected]
> Subject: RE: [Barracuda] XMLC Include Files
>
>
>
> Hi Christian,
>
> Doesn't this sort of defeat the purpose of using SSI's in the
> first place?  If you have a bunch of .html mockup files which
> reference the same markup, but don't use ssi's directly, rather
> you do the <!-- start foo.ssi --> stuff, then you are just
> repeating this information in all your .html files where you
> could have put that info in .ssi files in the first place and
> just then glob copy all your .html files to .shtml files to work
> with IIS or Apache.  Maybe I'm missing something?
>
> Additionally, all this begs the question of the usefulness of the
> GenerateSSI taskdef and CopyReplace taskdef since, isn't this
> functionality already provided by the XMLC compiler anyway?  Why
> duplicate this with separate taskdefs?
>
> Jake
>
> At 10:40 AM 6/23/2003 -0600, you wrote:
>
> Hi Kirk,
>
> Barracuda has a CopyAndReplace taskdef which will process/resolve
> .ssis in files. Attached is a copy of one of the build.xml files
> we use here that will demonstrate how to use it (just search for
> CopyAndReplace).
>
> The basic idea is we have all our markup in *.html files, with
> specific "ssi" chunks wrapped with
> <!-- start foo.ssi -->
>    ssi markup goes here
> <!-- end foo.ssi -->
> We use the GenerateSSI taskdef to process the *.html files and
> create .ssi files from them. These ssi files are then referenced
> in *.shtml files (which IIS or Apache will resolve, allowing
> designers to preview the mockups).
>
> We then use the CopyAndReplace taskdef to move the *.shtml files
> to the target directory (resolving ssis in the process) where
> XMLC will actually compile them.
>
> That make sense? Its a little complicated, but it works quite well...
>
> Christian
> ----------------------------------------------
> Christian Cryder
> Internet Architect, ATMReports.com
> Project Chair, BarracudaMVC - http://barracudamvc.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
>
> -----Original Message-----
>
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Kirk Daries
>
> Sent: Monday, June 23, 2003 4:37 AM
>
> To: [email protected]
>
> Subject: [Barracuda] XMLC Include Files
>
>
> Hi Guys,
>
>
>
> Is there anyway to set/use property files with the server side
> include files?
>
>
>
> E.g.
>
>
>
> Instead of hard coding
>
> <!--#include
> file="../../../eworksportal/src_mockups/xmlc/ReportPageFooter.ssi"-->
>
>
>
> Use something like this...
>
>
>
> <!--#include file="${REPORT_PAGE_FOOTER}"-->
>
>
>
> ???
>
>
>
> Regards
>
> KD
>
>
>
> Ps.
>
> Just want to avoid hard coding the path to the include files to
> make maintenance easier later..