List of events and element groups

Hi ho,

Age-old question here: if I wanted to manage a list of
events (not a  
huge list, but a list) in Bricolage, what would be way to go
about it?  
I re-read a few threads on the list -- including this one:
http://tinyurl.com/2wvlaf 
  -- but I'm still left scratching my head on:

1. Is using the Cover Date and Expire Date the best way to
manage the  
"dates" of these event stories?
2. If so, how does one get around having a publish date in
the future  
(if you were to want event detail stories accessible)?
3. If not, then how would you sort the list of events in the
usual  
"closest to today" sort order?

In trying to think this through, it reminded me that I've
been meaning  
to ask about the idea of element groups or sets, e.g.:
instead of  
selecting a custom field widget like Textarea, having
something like  
"Date range" or "Date and time range,"
which would provide a set of  
elements (similar to the cover date options) to facilitate
the easy  
presentation of the fields necessary for that information.

Other example would be something like address, e.g.: Street,
City,  
State / Province, Zip / Postal, Country.

Thoughts on both?

Phillip.

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.community
bandwidth.ca

>Age-old question here: if I wanted to manage a list of
events (not a  
>huge list, but a list) in Bricolage, what would be way
to go about it?  
>I re-read a few threads on the list -- including this
one: http://tinyurl.com/2wvlaf 
>  -- but I'm still left scratching my head on:

Depends on whether your events are to correspond to a single
story per event or whether you'll have one story with many
events.

Either way, you probably want to be create sub-elements that
contain a start date, end date, and other scheduling
attributes that will be filled in for any event.

Bricolage has native date field type for dates and you can
specific the granularity as well (all the way down to
minutes or seconds I believe).

1. Is using the Cover Date and Expire Date the best way to
manage the  
"dates" of these event stories?

In my opinion, no, although it would make retrieving lists
of events in a sorted order slightly easier for your
template developers, but it's really not that hard to
retrieve a list of all events, then sort them in your
template.  Perhaps there is already a Bric-API feature for
sorting stories based on a custom field?  I'm not sure.


>2. If so, how does one get around having a publish date
in the future  
>(if you were to want event detail stories accessible)?

See above -- I wouldn't override publish date, cover date,
or expire date -- although if you use any of those, cover
date is probably the most benign.


>3. If not, then how would you sort the list of events in
the usual  
>"closest to today" sort order?

http:/
/www.perlfect.com/articles/sorting.shtml

>In trying to think this through, it reminded me that
I've been meaning  
>to ask about the idea of element groups or sets, e.g.:
instead of  
>selecting a custom field widget like Textarea, having
something like  
>"Date range" or "Date and time
range," which would provide a set of  
>elements (similar to the cover date options) to
facilitate the easy  
>presentation of the fields necessary for that
information.
>
>Other example would be something like address, e.g.:
Street, City,  
>State / Province, Zip / Postal, Country.

Sure sounds like sub-elements to me.  Or are you seeking to
flatten the way that subelements are presented for entry? 
If so, the ajax mods that will be in 2.0 do that pretty well
-- does not require a page transition to enter data for
sub-elements.

On Mar 19, 2008, at 16:29, Phillip Smith wrote:

> In trying to think this through, it reminded me that
I've been  
> meaning to ask about the idea of element groups or
sets, e.g.:  
> instead of selecting a custom field widget like
Textarea, having  
> something like "Date range" or "Date and
time range," which would  
> provide a set of elements (similar to the cover date
options) to  
> facilitate the easy presentation of the fields
necessary for that  
> information.

Is that not what subelements are for?

> Other example would be something like address, e.g.:
Street, City,  
> State / Province, Zip / Postal, Country.
>
> Thoughts on both?

Again, is that not just a subelement?

Best,

David

On Mar 19, 2008, at 23:40, Beaudet, David P. wrote:

> Bricolage has native date field type for dates and you
can specific  
> the granularity as well (all the way down to minutes or
seconds I  
> believe).

Miocrseconds.

> In my opinion, no, although it would make retrieving
lists of events  
> in a sorted order slightly easier for your template
developers, but  
> it's really not that hard to retrieve a list of all
events, then  
> sort them in your template.  Perhaps there is already a
Bric-API  
> feature for sorting stories based on a custom field? 
I'm not sure.

Is it not possible to have the database sort them?

Best,

David

On 20-Mar-08, at 2:40 AM, Beaudet, David P. wrote:
> Bricolage has native date field type for dates and you
can specific  
> the granularity as well (all the way down to minutes or
seconds I  
> believe).

OMG! I can't believe that I've overlooked this until today! 
;-P

Thanks!

Any pointers on getting the results of the date field to
output in ISO  
8601 format (http://microfor
mats.org/wiki/iso-8601)?

On 20-Mar-08, at 1:30 PM, David E. Wheeler wrote:
>
> Again, is that not just a subelement?

Yes. But, per David's question "Or are you seeking to
flatten the way  
that subelements are presented for entry?" -- the
answer is "yes" (in  
a perfect world). For example, if I'm commonly adding a
phone number  
custom field to an element, I'd like it to always have three
inputs  
[area code] [prefix] [number] side-by-side, or a street
address to  
automatically have the group of elements necessary, e.g., a
populated  
list of states, provinces, and countries.

Just a thought.

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.community
bandwidth.ca

I agree that this would be useful. Also, it's already done!
(The AJAX
interface in trunk achieves this by showing subelements
inline.)

Now the trick is getting v. 1.10 merged with trunk...

We're due to sponsor a feature (or two or three or four).
Does anybody
know where the current merge process is (that is, how much
merging has
been completed on last year's SOC pieces)?

Cheers,

Bret


> Yes. But, per David's question "Or are you seeking
to flatten the way  
> that subelements are presented for entry?" -- the
answer is "yes" (in  
> a perfect world). For example, if I'm commonly adding a
phone number  
> custom field to an element, I'd like it to always have
three inputs  
> [area code] [prefix] [number] side-by-side, or a street
address to  
> automatically have the group of elements necessary,
e.g., a populated  
> list of states, provinces, and countries.

-- 
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bretpectopah.com
www.pectopah.com

If you use the built-in date element, just pass a
strftime-compatible  
formatting string to its get_value method:

$e->get_value('%Y-%m-%d');


On 20-Mar-08, at 1:44 PM, Phillip Smith wrote:
>
> OMG! I can't believe that I've overlooked this until
today!  ;-P
>
> Thanks!
>
> Any pointers on getting the results of the date field
to output in  
> ISO 8601 format (http://microfor
mats.org/wiki/iso-8601)?

---
Greg Heo
web/software systems developer
gregnode79.com
416.826.7630

On Mar 20, 2008, at 10:44, Phillip Smith wrote:

> Yes. But, per David's question "Or are you seeking
to flatten the  
> way that subelements are presented for entry?" --
the answer is  
> "yes" (in a perfect world). For example, if
I'm commonly adding a  
> phone number custom field to an element, I'd like it to
always have  
> three inputs [area code] [prefix] [number]
side-by-side, or a street  
> address to automatically have the group of elements
necessary, e.g.,  
> a populated list of states, provinces, and countries.

Well, here's a feature request: Allow subelements to be
added inline  
to an element, so that all of their fields just show up. So
if you  
create a "Phone Number" subelement with those
three fields, and check  
the "Inline" checkbox, when you add it to an
element, it will be  
inline like other fields, rather than clickable as a
subelement.

Or you can just use Bulk Edit. 

David

On Mar 20, 2008, at 11:00, Bret Dawson wrote:

> I agree that this would be useful. Also, it's already
done! (The AJAX
> interface in trunk achieves this by showing subelements
inline.)
>
> Now the trick is getting v. 1.10 merged with trunk...
>
> We're due to sponsor a feature (or two or three or
four). Does anybody
> know where the current merge process is (that is, how
much merging has
> been completed on last year's SOC pieces)?

I'll do it next month. I'll put aside a couple of days for
it.

Best,

David

On 20-Mar-08, at 2:16 PM, Greg Heo wrote:
> If you use the built-in date element, just pass a
strftime- 
> compatible formatting string to its get_value method:
>
> $e->get_value('%Y-%m-%d');'

Greg: do you know if I can sort on that element?

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.community
bandwidth.ca