Mike and David, thanks for your help!
I did not plan to use Bric as middleware, what I was questioning whether
it is ok by other application to pull Bric managed content directly from
its database or export it first. In the past I've been working mostly
with dynamic applications (built on BV, Weblogic, ATG, etc), which tend
to make you think more in terms of pull (and cache), but I recognize
that this is not always the only or best option.
Mike, I'll think about your suggestion about static calendar, this may
be not as difficult as I thought. Well, I guess it is time to learn
Mason.
And of course having software as nice as Bric makes me want to take
advantage of it's capabilities!
Thanks again.
Alex
-----Original Message-----
From: Mike Slattery [mailto:drowsy@mac.com]
Sent: Monday, February 17, 2003 4:04 PM
To: Alex Epshteyn
Cc: bricolage-general@lists.sourceforge.net
Subject: Re: [Bricolage-General] Content delivery for a dynamic site
Alex,
Warning: I'm not qualified to give an "official" answer! But here
goes:
Yeah, in my travels, sometimes I've wanted Bric to be more of a
transaction engine, or a real-time web-publishing engine, but it's not
middleware. What Bric excels at is the opposite, and it has a lot of
value: allowing folks to imagine and re-imagine their static but
update-able site while hiding all of the db juggling that needs to
happen.
You don't need to write SQL to make an updateable web site, and that is
precisely why we can put this in our clients' hands. You can do rapid
prototyping to see how the element structures should look, everything
has human readable names, etc.
> I suspect that using Mason templates
> very cleverly, one could generate calendars for various days, weeks,
> months and various event category selections, but IMHO it is more
> natural to do this type of processing at request time. I wonder what
> you think about these options?
With the calendaring idea, I would go with push over pull if you are
using Bric.
You could use Bric to create elements for events that drill down into
month/week/day and include categories within the psuedo-record for each
event in a master XHTML or XML doc. An XSL file on the server could
serve up just what is needed from the master doc.
AND/OR
The master doc(s) could be built in Bric, relying on the related
stories function. Each event could be thought of as its own doc on
this case. An event doc could be related by (human readable!) name to
one or more master docs, maybe one per category, and per week-of-year,
month, day etc.
Then schedule a re-pub of the master docs every XX minutes using a
command-line app based on bric_publish tool.
> Besides the elements for calendar events and news, I am not too clear
> yet on what parts of the database I would be interested in exporting,
> I have to get more familiar with the database.
When you architect your bricolage site, you have to envision your
content as documents that are made up of elements. These elements
can contain other elements, etc...
Once you map out your needs in terms of elements, the quickest way to
get at an element is through the Application itself or the Bric::
family of modules.
You can create as many elements and relationships as needed. Bric does
not create new tables for any of the new elements, but instead creates
them within the apps tables in terms of their relationships among
elements as they relate to each other and the top-level. It's not as
clean as designing tables for each element and such, and just digging
in. The schema is daunting because the application is designed to deal
with all of these possibilities, and you'll end up chasing a lot of
numeric keys around!
But you don't have to, which is the best part.
The best way to get at them is through the Bric:: modules or the SOAP
interface. I'm experimenting with a SOAP dump to one or more XML:DB
engines, namely the exist xmldb and the sleepycat-berkeley dbxml, which
would add a lot of fielded searchability to our Bric-made sites.
Cheers,
Mike
On Monday, February 17, 2003, at 04:40 PM, Alex Epshteyn wrote:
> Hi Mike,
>
> The goal is more the second option - dynamically pull the content
> stored
> in Bricolage database. This would be in addition to using Bricolage
for
> publishing of other content using Mason templates. A simple scenario -
> calendar of events, where events are entered using Bricolage, but
> pulled
> from its database at request time. I suspect that using Mason
templates
> very cleverly, one could generate calendars for various days, weeks,
> months and various event category selections, but IMHO it is more
> natural to do this type of processing at request time. I wonder what
> you
> think about these options?
>
> Besides the elements for calendar events and news, I am not too clear
> yet on what parts of the database I would be interested in exporting,
> I have to get more familiar with the database. I am just trying to
> understand the best way to use Bricolage, and as most of the
> applications I run across have both the static and dynamic parts I
> would like to form an opinion on the best way of dealing with that and
> hear about an "official" way ;-).
>
> Your suggestion of using SOAP and extract data into separate db would
> work for us - all we would have to do is to implement simple logic to
> remove deleted content, update, etc.
>
> Still, it would be nice to have a general purpose database publishing
> process, perhaps configured using some XML based mapping?
>
> Thanks for your help,
>
> Alex
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general