Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Bricolage: users

[Bricolage-General] Content delivery for a dynamic site

 

 

Bricolage users RSS feed   Index | Next | Previous | View Threaded


Alex.Epshteyn at razorfish

Feb 17, 2003, 8:58 AM

Post #1 of 9 (537 views)
Permalink
[Bricolage-General] Content delivery for a dynamic site

I am new to this list, so I apologize if this question had been answered
before.

We are working on a site that is primarily static, but has a few dynamic
pages. From what I was able to learn in this list, it is a matter of
protecting the code for dynamic access (which can be written using any
technology) during burn process and accessing the content that has to be
delivered dynamically using pretty much anything that can get content
from the database (Bricolage will simply generate templates for your
dynamic template system of choice - any Perl based templating system,
JSP, ASP, etc).

I assumed that for the cases like this Bricolage will have some public
API to allow apps to get at its content, but could not find anything in
the documentation except for the SOAP interface. I would like to avoid
accessing database directly, as I don't wont to violate encapsulation
and this approach is likely to break in case of the Bricolage schema
changes.

So the question is - what is the design pattern for mixed static/dynamic
sites?

What am I missing?

Thanks,
Alex



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-general


drowsy at mac

Feb 17, 2003, 12:50 PM

Post #2 of 9 (523 views)
Permalink
Re: [Bricolage-General] Content delivery for a dynamic site [In reply to]

Alex,

I'm not sure what the goal is: to regularly publish database driven
content that bricolage would pull in.
- this would be very possible with a Mason template that accessed
another DB
or are you trying to use bricolage to allow folks to generate content
for use elsewhere?
- I think SOAP would handle most of that.

From what I've observed the info stored in bricolage is not meant for
use in other systems unless it is exported to them as full documents or
collections of docs. More atomic access does make sense right now.

I'd assume that any data stores for dynamic content would be external
to Bricolage, but if you wished to create content to add to these data
stores, you could export docs to them. The soap interface can give
you docs to feed to any XML based import routine for other services, if
you want to get at the bricolage-created content somehow.

It would be interesting to hear what parts of the database you were
thinking of accessing outside of bric. I've been thinking of the User
and Group spaces, but not much beyond that.

Mike

On Monday, February 17, 2003, at 11:58 AM, Alex Epshteyn wrote:

> I am new to this list, so I apologize if this question had been
> answered
> before.
>
> We are working on a site that is primarily static, but has a few
> dynamic
> pages. From what I was able to learn in this list, it is a matter of
> protecting the code for dynamic access (which can be written using any
> technology) during burn process and accessing the content that has to
> be
> delivered dynamically using pretty much anything that can get content
> from the database (Bricolage will simply generate templates for your
> dynamic template system of choice - any Perl based templating system,
> JSP, ASP, etc).
>
> I assumed that for the cases like this Bricolage will have some public
> API to allow apps to get at its content, but could not find anything in
> the documentation except for the SOAP interface. I would like to avoid
> accessing database directly, as I don't wont to violate encapsulation
> and this approach is likely to break in case of the Bricolage schema
> changes.
>
> So the question is - what is the design pattern for mixed
> static/dynamic
> sites?
>
> What am I missing?
>
> Thanks,
> Alex
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Bricolage-General mailing list
> Bricolage-General [at] lists
> https://lists.sourceforge.net/lists/listinfo/bricolage-general
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-general


drowsy at mac

Feb 17, 2003, 12:54 PM

Post #3 of 9 (528 views)
Permalink
Re: [Bricolage-General] Content delivery for a dynamic site [In reply to]

Whoops,

On Monday, February 17, 2003, at 03:50 PM, Mike Slattery wrote:

> More atomic access does [NOT] make sense right now

Sorry bout that.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-general


Alex.Epshteyn at razorfish

Feb 17, 2003, 1:40 PM

Post #4 of 9 (522 views)
Permalink
RE: [Bricolage-General] Content delivery for a dynamic site [In reply to]

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

-----Original Message-----
From: Mike Slattery [mailto:drowsy [at] mac]
Sent: Monday, February 17, 2003 12:51 PM
To: Alex Epshteyn
Cc: bricolage-general [at] lists
Subject: Re: [Bricolage-General] Content delivery for a dynamic site


Alex,

I'm not sure what the goal is: to regularly publish database driven
content that bricolage would pull in.
- this would be very possible with a Mason template that accessed
another DB
or are you trying to use bricolage to allow folks to generate content
for use elsewhere?
- I think SOAP would handle most of that.

From what I've observed the info stored in bricolage is not meant for
use in other systems unless it is exported to them as full documents or
collections of docs. More atomic access does make sense right now.

I'd assume that any data stores for dynamic content would be external
to Bricolage, but if you wished to create content to add to these data
stores, you could export docs to them. The soap interface can give
you docs to feed to any XML based import routine for other services, if
you want to get at the bricolage-created content somehow.

It would be interesting to hear what parts of the database you were
thinking of accessing outside of bric. I've been thinking of the User
and Group spaces, but not much beyond that.

Mike

On Monday, February 17, 2003, at 11:58 AM, Alex Epshteyn wrote:

> I am new to this list, so I apologize if this question had been
> answered
> before.
>
> We are working on a site that is primarily static, but has a few
> dynamic
> pages. From what I was able to learn in this list, it is a matter of
> protecting the code for dynamic access (which can be written using any
> technology) during burn process and accessing the content that has to
> be
> delivered dynamically using pretty much anything that can get content
> from the database (Bricolage will simply generate templates for your
> dynamic template system of choice - any Perl based templating system,
> JSP, ASP, etc).
>
> I assumed that for the cases like this Bricolage will have some public

> API to allow apps to get at its content, but could not find anything
> in the documentation except for the SOAP interface. I would like to
> avoid accessing database directly, as I don't wont to violate
> encapsulation and this approach is likely to break in case of the
> Bricolage schema changes.
>
> So the question is - what is the design pattern for mixed
> static/dynamic
> sites?
>
> What am I missing?
>
> Thanks,
> Alex
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Bricolage-General mailing list Bricolage-General [at] lists
> https://lists.sourceforge.net/lists/listinfo/bricolage-general
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-general


david at kineticode

Feb 17, 2003, 4:01 PM

Post #5 of 9 (520 views)
Permalink
Re: [Bricolage-General] Content delivery for a dynamic site [In reply to]

On Monday, February 17, 2003, at 01:40 PM, Alex Epshteyn wrote:

> 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?

Bricolage isn't designed to be an app server. It expects you to use
another system (CGI, Servlets, WebObjects, etc.) to handle dynamic
sites -- sites that are really applications (like calendaring systems
and shopping cart systems). If you want to manage a particular kind of
content in Bricolage that you want dynamically generated, the simplest
option is to set up a cron job to autopublish a story with your content
every five minutes or so -- or only when the content actually changes.

> 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 ;-).

Well, you can use the standard Bricolage API to access objects. Check
out Bric::Biz::Asset::Business::Story for a start. There are many
others, as well -- Bric::Biz::Asset::Business::Parts::Tile::Container
is an important class for accessing story elements.

But as I said, Bricolage isn't an app server -- it's a content
management and publishing system. For sites with some dynamic content
(the type that needs to be pulled from a database), use an application
server designed to do that sort of thing. Use Bricolage to generate the
static content for such sites, as well as to manage the look and feel
of the dynamic application section of a site.

HTH,

David
--
David Wheeler AIM: dwTheory
david [at] kineticode ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory [at] jabber
Kineticode. Setting knowledge in motion.[sm]



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-general


drowsy at mac

Feb 17, 2003, 4:04 PM

Post #6 of 9 (527 views)
Permalink
Re: [Bricolage-General] Content delivery for a dynamic site [In reply to]

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 [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-general


david at kineticode

Feb 17, 2003, 4:15 PM

Post #7 of 9 (530 views)
Permalink
Re: [Bricolage-General] Content delivery for a dynamic site [In reply to]

On Monday, February 17, 2003, at 04:04 PM, Mike Slattery wrote:

> Warning: I'm not qualified to give an "official" answer! But here
> goes:

Yeah, but it's close enough. :-) Well said.

Regards,

David

--
David Wheeler AIM: dwTheory
david [at] kineticode ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory [at] jabber
Kineticode. Setting knowledge in motion.[sm]



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-general


Alex.Epshteyn at razorfish

Feb 17, 2003, 5:01 PM

Post #8 of 9 (522 views)
Permalink
RE: [Bricolage-General] Content delivery for a dynamic site [In reply to]

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 [at] mac]
Sent: Monday, February 17, 2003 4:04 PM
To: Alex Epshteyn
Cc: bricolage-general [at] lists
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 [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-general


david at kineticode

Feb 17, 2003, 5:12 PM

Post #9 of 9 (526 views)
Permalink
Re: [Bricolage-General] Content delivery for a dynamic site [In reply to]

On Monday, February 17, 2003, at 05:01 PM, Alex Epshteyn wrote:

> Mike and David, thanks for your help!

No problem!

> 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.

The best way to do it in Bricolage is via the SOAP server. Several
folks have mumbled about creating GUI front-ends for editing assets by
pulling content from the SOAP server, and that's real-time access. And
of course you can use the API directly (although only where you have it
and all the proper libraries installed -- you can more easily use SOAP
remotely).

> 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.

Mason is cool. :-)

> And of course having software as nice as Bric makes me want to take
> advantage of it's capabilities!

Glad you like it -- enjoy!

David

--
David Wheeler AIM: dwTheory
david [at] kineticode ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory [at] jabber
Kineticode. Setting knowledge in motion.[sm]



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-general

Bricolage users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.