Mailing List Archive: Bricolage: devel

[Bricolage-Devel] "Utility" Pages in Bric

Index | Next | Previous | View Threaded

Jason at about-inc

Feb 18, 2002, 3:27 PM

Post #1 of 8 (942 views)
Permalink

[Bricolage-Devel] "Utility" Pages in Bric

Is there a way to handle utility-type pages in Bricolage? Things like

Privacy Policy
About Us
Advertiser Info
Newsletter Signup Page

And so on. Basically one-off type pages that are static, and don't fit into
the story motif (so far as I can tell).

If not, perhaps this is something to tack onto the ToDo list?

Thanks,
Jason

david at kineticode

Feb 18, 2002, 6:40 PM

Post #2 of 8 (906 views)
Permalink

Re: [Bricolage-Devel] "Utility" Pages in Bric [In reply to]

On Mon, 2002-02-18 at 15:27, Merrick, Jason wrote:
> Is there a way to handle utility-type pages in Bricolage? Things like
>
> Privacy Policy
> About Us
> Advertiser Info
> Newsletter Signup Page

Well, yes. I mean, everything with text content in Bricolage is a
"Story," but that's just a convention. What these are are special
categories (/about, /about/privacy, /about/ad_info, /newletter) with
Fixed stories that contain the content you want. If that content doesn't
change very much, you can even put it all into the template, if you want
(though I don't really recommend that). Then just change them and
publish them as you need to.

HTH,

David

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

_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

Jason at about-inc

Feb 18, 2002, 9:18 PM

Post #3 of 8 (907 views)
Permalink

RE: [Bricolage-Devel] "Utility" Pages in Bric [In reply to]

Hmm. I can see this becoming a problem from the user POV, especially given
the way categories are handled. This would basically add at least 5, and in
some cases a dozen or more, categories to the category dropdown. Since
these pags are used maybe once a year, I think of their presence in the
category dropdown as confounding.

Any thoughts on giving users more control over filenames, and in the case of
media, paths?

This way you could simply create a dozen or so fixed stories at the root or
in /utility/ with the names

aboutus.html
privacy.html
and_so_on.html

This extra control would be especially useful in media. So far as I know it
would be very difficult to use "utility" images, such as buttons, logos,
etc, generically across installs. However if you could force all buttons to
live in /images/buttons/1.gif, 2.gif, etc., you could use this same schema
across installs.

Or am I off my rocker? Thoughts?

Thanks,
Jason

-----Original Message-----
From: David Wheeler
To: Merrick, Jason
Cc: 'bricolage-devel [at] lists'
Sent: 2/18/02 9:40 PM
Subject: Re: [Bricolage-Devel] "Utility" Pages in Bric

On Mon, 2002-02-18 at 15:27, Merrick, Jason wrote:
> Is there a way to handle utility-type pages in Bricolage? Things like

>
> Privacy Policy
> About Us
> Advertiser Info
> Newsletter Signup Page

Well, yes. I mean, everything with text content in Bricolage is a
"Story," but that's just a convention. What these are are special
categories (/about, /about/privacy, /about/ad_info, /newletter) with
Fixed stories that contain the content you want. If that content doesn't
change very much, you can even put it all into the template, if you want
(though I don't really recommend that). Then just change them and
publish them as you need to.

HTH,

David

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

david at kineticode

Feb 18, 2002, 10:14 PM

Post #4 of 8 (907 views)
Permalink

RE: [Bricolage-Devel] "Utility" Pages in Bric [In reply to]

On Mon, 2002-02-18 at 21:18, Merrick, Jason wrote:
> Hmm. I can see this becoming a problem from the user POV, especially given
> the way categories are handled. This would basically add at least 5, and in
> some cases a dozen or more, categories to the category dropdown. Since
> these pags are used maybe once a year, I think of their presence in the
> category dropdown as confounding.

Well, on the To Do list is to make categories more hierarchical. If, for
example, you put all of those pages you mentioned into a top-level
category (e.g., /about), once we got 'round to creating a hierachical
interface for navigating categories, users would only see /about when
they started navigating, and none of its subcategories unless they
selected /about. 'Course, making category navigation truly hierarchical
is not something we're actively working on at the moment, but it is high
on the To Do list...

But currently, you can use permissions to limit the view of the relevant
categories to those users who actually need to see them.

> Any thoughts on giving users more control over filenames, and in the case of
> media, paths?

<snip />

Well, with media, this is already there. If you made those pages media
object -- that is, you generated the raw HTML for each one and uploaded
it as a media object, and them published the media object, it would get
the name of the file. So if you uploaded an "aboutus.html" raw HTML page
and published it in the root (/) category, then the page would be called
/about/about.html. But then these wouldn't be manageable as stories.

> This extra control would be especially useful in media. So far as I know it
> would be very difficult to use "utility" images, such as buttons, logos,
> etc, generically across installs. However if you could force all buttons to
> live in /images/buttons/1.gif, 2.gif, etc., you could use this same schema
> across installs.

<snip />

You can in fact do this now. Create an /images category, and then a
/buttons subcategory in /images, and then upload graphics called 1.gif
and 2.gif into that category.

As for stories, Sam and I have talked about adding the ability to use
the story slug for the file name. That will likely be added in the next
couple of months.

HTH,

David

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

_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

mdorman at mallet-assembly

Feb 19, 2002, 7:15 AM

Post #5 of 8 (910 views)
Permalink

Re: [Bricolage-Devel] "Utility" Pages in Bric [In reply to]

David Wheeler <david [at] kineticode> writes:
> 'Course, making category navigation truly hierarchical is not
> something we're actively working on at the moment, but it is high on
> the To Do list...

When/if it does make it to the top, I have some pg/pgsql code for
transparently implementing arbitrarily nested trees in PostgreSQL
tables, stolen from the OpenACS system, and it works really well.

At least, if you get to this before PostgreSQL 7.3 which may have a
built-in tree datatype, if those wily OpenFTS people keep up as they
are.

Mike.

_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

sam at tregar

Feb 19, 2002, 9:21 AM

Post #6 of 8 (907 views)
Permalink

Re: [Bricolage-Devel] "Utility" Pages in Bric [In reply to]

On 19 Feb 2002, Michael Alan Dorman wrote:

> When/if it does make it to the top, I have some pg/pgsql code for
> transparently implementing arbitrarily nested trees in PostgreSQL
> tables, stolen from the OpenACS system, and it works really well.

Ooo, can I see? (That is, assuming OpenACS is under a BSD-or-freer
license.) One thing I'd like to do soon is do some re-design of the
category system. Currently it's based on the "Grp" system in Bricolage
which is either so complicated or just so under-documentated that I can't
make heads or tails of it.

-sam

_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

david at kineticode

Feb 19, 2002, 10:08 AM

Post #7 of 8 (904 views)
Permalink

Re: [Bricolage-Devel] "Utility" Pages in Bric [In reply to]

On Tue, 2002-02-19 at 09:21, Sam Tregar wrote:

> Ooo, can I see? (That is, assuming OpenACS is under a BSD-or-freer
> license.) One thing I'd like to do soon is do some re-design of the
> category system. Currently it's based on the "Grp" system in Bricolage
> which is either so complicated or just so under-documentated that I can't
> make heads or tails of it.

Yeah, I'd like to see, too. The answer to your implicit question, Sam,
is "both." The group system certainly could use better documentation,
but it's also being used for stuff that is IMHO way beyond what one
should expect of a group system. But in the days that some of the
fundamental classes of Bricolage were developed (Group, Attribute,
etc.), there were some different design philosophies at play...

However, the UI can be made to use a hierarchical navigation with
Categories with the current API; it's just a matter of finding the tuits
to do it.

Regards,

David

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

_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

mdorman at mallet-assembly

Feb 19, 2002, 1:45 PM

Post #8 of 8 (905 views)
Permalink

Re: [Bricolage-Devel] "Utility" Pages in Bric [In reply to]

Sam Tregar <sam [at] tregar> writes:
> Ooo, can I see? (That is, assuming OpenACS is under a BSD-or-freer
> license.)

OpenACS is GPL---it is, of course, the subject of religious wars
whether that's more or less free than BSD. :-) Looking at Bricolage's
license, I suspect it's incompatible.

However, the OpenACS people's implementation of this stuff is based on
the work of Miguel Sofer <mig [at] utdt> whose paper describing his
representation can be found at http://www.utdt.edu/~mig/trees.tar.gz.

Turns out, this also include a PostgreSQL implementation that has no
explicit license on it---so you could ask, and I suspect he'd let you
have it under a compatible license.

For that matter, I wonder whether the OpenACS people might be willing
to relicense it, seeing as how their code is basically just a cosmetic
clean-up of Miguel's code.

A really good discussion of how to do trees in PostgreSQL (as a way to
replace Oracle's CONNECT BY) this by various OpenACS people is at:

http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0000j6&topic_id=12&topic=OpenACS%204%2e0%20Design

It includes implementation in pl/tcl of another implementation, but
it's noted as being less efficient than Sofer's structure.

Mike.

_______________________________________________
Bricolage-Devel mailing list
Bricolage-Devel [at] lists
https://lists.sourceforge.net/lists/listinfo/bricolage-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads