Mailing List Archive: Next Steps for Bricolage Development

Next Steps for Bricolage Development

May 15, 2010, 10:18 AM

Post #1 of 32 (12766 views)

Now that 2.0 is out I wanted to start a thread to see what people thought about the next steps for Bricolage's development. Right now I have the code that will enable various single-sign-on applications that take advantage of Apache's authentication modules, so I was going to commit that at the next convenient moment.

Also, a while ago I started refactoring the CSS and a little bit of the layout to make things faster and nicer to look at. This is something that will break existing custom skins (not that 2.0 didn't do enough of that anyway), so it will not be a trivial thing for people to upgrade.

And that's really what I have. David said that the code which allowed editing on preview did not make it in to 2.0, and I've pretty much come around to the idea that this is a feature which should be in trunk. I believe that WHO was fine with contributing the code, but correct me if I'm wrong. If that's the case, does anyone have any objections or tuits?

Other than those three things, are there any features that others would like to see in 2.2 or are willing to work on?

Something I would also bring up is the possibility of making Bricolage thread safe for mod_perl2 and Apache 2.2 (no more relying on prefork). This sort of improvement would take a lot of work and effort. It's not something that one person could do on their own, and it's not something that would happen right away. This might be a Bricolage 3.0/4.0 sort of thing. We'd have to check a lot of Perl modules and probably contribute code to a few, in addition to the Bric codebase.

Keep in mind that I personally don't know anything about the performance impact or development trade off this would have it relates to mod_perl applications. The only thing I know is how apache itself consumes far fewer resources when compiled with mpm-worker. So it would be great if someone with more knowledge could speak on whether it would be worth it to even engage in an effort like that.

-Matt

Re: Next Steps for Bricolage Development [ In reply to ]

david at kineticode

May 15, 2010, 8:47 PM

Post #2 of 32 (12604 views)

On May 15, 2010, at 10:18 AM, Matthew Rolf wrote:

> Now that 2.0 is out I wanted to start a thread to see what people thought about the next steps for Bricolage's development. Right now I have the code that will enable various single-sign-on applications that take advantage of Apache's authentication modules, so I was going to commit that at the next convenient moment.

+1

> Also, a while ago I started refactoring the CSS and a little bit of the layout to make things faster and nicer to look at. This is something that will break existing custom skins (not that 2.0 didn't do enough of that anyway), so it will not be a trivial thing for people to upgrade.

Yes, already true of the upgrade to 2.0.

> And that's really what I have. David said that the code which allowed editing on preview did not make it in to 2.0, and I've pretty much come around to the idea that this is a feature which should be in trunk. I believe that WHO was fine with contributing the code, but correct me if I'm wrong. If that's the case, does anyone have any objections or tuits?

There is some work on it in this fork/branch:

http://github.com/brewt/bricolage/tree/dev_inline_edit.

Also saw this "Word import" branch:

http://github.com/brewt/bricolage/commits/dev_who_word_import

Adrian, you around? What's the status of these?

> Other than those three things, are there any features that others would like to see in 2.2 or are willing to work on?

I sent a message on May 5th to gauge interest in adding video and audio metadata.

http://marc.info/?l=bricolage-devel&m=127308131029193

But I also wouldn't mind seeing someone pick up input channels, which Marshall did a lot of work on in 2005. I think it just needed UI work. The back end would likely need quite a bit of updating, of course. Branch:

http://github.com/bricoleurs/bricolage/tree/dev_ics

> Something I would also bring up is the possibility of making Bricolage thread safe for mod_perl2 and Apache 2.2 (no more relying on prefork). This sort of improvement would take a lot of work and effort. It's not something that one person could do on their own, and it's not something that would happen right away. This might be a Bricolage 3.0/4.0 sort of thing. We'd have to check a lot of Perl modules and probably contribute code to a few, in addition to the Bric codebase.

Yeah, not anywhere on on my list.

> Keep in mind that I personally don't know anything about the performance impact or development trade off this would have it relates to mod_perl applications. The only thing I know is how apache itself consumes far fewer resources when compiled with mpm-worker. So it would be great if someone with more knowledge could speak on whether it would be worth it to even engage in an effort like that.

I think that would only happen if someone *really* cared. The vast majority of mod_perl installations use prefork, AFAIK, and there is little reason to switch.

Best,

David

Re: Next Steps for Bricolage Development [ In reply to ]

May 16, 2010, 12:39 PM

Post #3 of 32 (12607 views)

Honestly, if we implemented the stuff outlined here, I think that would make a nice little feature set for a 2.2. I guess I should get committing and working on that css.

I second the idea of video meta data, but I doubt I could take it on. So it would be nice if someone else could.

> I think that would only happen if someone *really* cared. The vast majority of mod_perl installations use prefork, AFAIK, and there is little reason to switch.

Can you elaborate a little more on the "little reason to switch" part? Is there just not enough of a performance gain?

-Matt

Re: Next Steps for Bricolage Development [ In reply to ]

waldo at vqronline

May 16, 2010, 1:09 PM

Post #4 of 32 (12610 views)

On May 16, 2010, at 3:39 PM, Matthew Rolf wrote:
> I second the idea of video meta data, but I doubt I could take it on. So it would be nice if someone else could.

FWIW, I’m pulling out and storing video metadata for another, non-Bricolage project (in PHP), and at least with regard to getting data from the video file, it’s drop-dead simple. If Perl has an mplayer interface (and we want to make mplayer a Bricolage requirement), then that portion of this is trivial.

Best,
Waldo

---
Virginia Quarterly Review
One West Range, Box 400223
University of Virginia
Charlottesville, VA 22904-4223
434-243-4995

Re: Next Steps for Bricolage Development [ In reply to ]

david at kineticode

May 16, 2010, 8:53 PM

Post #5 of 32 (12605 views)

On May 16, 2010, at 1:09 PM, Waldo Jaquith wrote:

> FWIW, I’m pulling out and storing video metadata for another, non-Bricolage project (in PHP), and at least with regard to getting data from the video file, it’s drop-dead simple. If Perl has an mplayer interface (and we want to make mplayer a Bricolage requirement), then that portion of this is trivial.

http://search.cpan.org/perldoc?Video::Info

Best,

David

Re: Next Steps for Bricolage Development [ In reply to ]

david at kineticode

May 17, 2010, 10:03 AM

Post #6 of 32 (12593 views)

On May 16, 2010, at 12:39 PM, Matthew Rolf wrote:

> Honestly, if we implemented the stuff outlined here, I think that would make a nice little feature set for a 2.2. I guess I should get committing and working on that css.

Yes, thanks.

> I second the idea of video meta data, but I doubt I could take it on. So it would be nice if someone else could.

It would not be a difficult task.

>> I think that would only happen if someone *really* cared. The vast majority of mod_perl installations use prefork, AFAIK, and there is little reason to switch.
>
> Can you elaborate a little more on the "little reason to switch" part? Is there just not enough of a performance gain?

Not without measuring, no. I'm not sure what all would need to be done, but Bricolage requires a *lot* of CPAN modules, and auditing them for thread-safety would be a big thankless job.

Best,

David

Re: Next Steps for Bricolage Development [ In reply to ]

alex at gossamer-threads

May 17, 2010, 10:19 AM

Post #7 of 32 (12624 views)

Hi,

> > And that's really what I have. David said that the code which allowed
> > editing on preview did not make it in to 2.0, and I've pretty much come
> > around to the idea that this is a feature which should be in trunk. I
> > believe that WHO was fine with contributing the code, but correct me if
> > I'm wrong. If that's the case, does anyone have any objections or tuits?
>
> There is some work on it in this fork/branch:
>
> http://github.com/brewt/bricolage/tree/dev_inline_edit.

This is live for WHO and could get merged in.

> Also saw this "Word import" branch:
>
> http://github.com/brewt/bricolage/commits/dev_who_word_import
>
> Adrian, you around? What's the status of these?

This is waiting on WHO still. It's beta stage and useful if anyone wants
to give it a try, but will take some work probably.

> > Something I would also bring up is the possibility of making Bricolage
> > thread safe for mod_perl2 and Apache 2.2 (no more relying on prefork).
> > This sort of improvement would take a lot of work and effort. It's not
> > something that one person could do on their own, and it's not something
> > that would happen right away. This might be a Bricolage 3.0/4.0 sort of
> > thing. We'd have to check a lot of Perl modules and probably contribute
> > code to a few, in addition to the Bric codebase.

Yikes, definitely not worth it. You might see minor perf gains on a
windows platform where proc creation is expensive, but you would not see
anything noticable on a linux platform, and probably have to fight a ton
of bugs. For an application like Bricolage, this is really not that
important (does not need very high concurency or lots of very fast, very
short requests).

Cheers,

Alex

--
Alex Krohn <alex@gossamer-threads.com>

Re: Next Steps for Bricolage Development [ In reply to ]

bret at pectopah

May 17, 2010, 10:38 AM

Post #8 of 32 (12596 views)

OK, time for me to stick my hand up (hoping not to get it caught in a
helicopter blade).

I'll try the video/audio metadata piece. I'm having a busy month, but
I'm always having a busy month, so now's probably as good a time as any
to take something else on.

Cheers,

Bret

On Mon, 2010-05-17 at 10:03 -0700, David E. Wheeler wrote:
> On May 16, 2010, at 12:39 PM, Matthew Rolf wrote:
>
> > Honestly, if we implemented the stuff outlined here, I think that would make a nice little feature set for a 2.2. I guess I should get committing and working on that css.
>
> Yes, thanks.
>
> > I second the idea of video meta data, but I doubt I could take it on. So it would be nice if someone else could.
>
> It would not be a difficult task.
>
> >> I think that would only happen if someone *really* cared. The vast majority of mod_perl installations use prefork, AFAIK, and there is little reason to switch.
> >
> > Can you elaborate a little more on the "little reason to switch" part? Is there just not enough of a performance gain?
>
> Not without measuring, no. I'm not sure what all would need to be done, but Bricolage requires a *lot* of CPAN modules, and auditing them for thread-safety would be a big thankless job.
>
> Best,
>
> David
>
>
>

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

Re: Next Steps for Bricolage Development [ In reply to ]

david at kineticode

May 17, 2010, 11:01 AM

Post #9 of 32 (12602 views)

On May 17, 2010, at 10:38 AM, Bret Dawson wrote:

> OK, time for me to stick my hand up (hoping not to get it caught in a
> helicopter blade).
>
> I'll try the video/audio metadata piece. I'm having a busy month, but
> I'm always having a busy month, so now's probably as good a time as any
> to take something else on.

Hints:

Bric::Biz::Asset::Media uses Bric::App::MediaFunc to populate autopopulated fields for images in its upload_file() method. You'll need to modify Bric::App::MediaFunc to get video and/or audio metadata from a file and return it in an accessor.

But you'll notice that it uses _get_auto_fields() to get a list of metadata fields. They're hard-coded into the database in sql/Pg/Bric/Biz/ElementType/Parts/FieldType.val and sql/mysql/Bric/Biz/ElementType/Parts/FieldType.val. You'd need to add any new fields to this table (with biz_pkg 51 for video and 49 for audio) write a migration script to update existing installs to have the same data.

Getting back to MediaFunc, I frankly think it should be refactored so that instead of offering accessors to metadata, which are currently all image-oriented, it should have a method that returns a hash with the appropriate metadata. The keys would be field key names and the values would be the values. Then it won't be so image-specific, and upload_media() can be modified to use key names (should have been long ago) and to access the has specifically.

Make sense? I imagine that this is just a few hours work, plus tests, and whatever time you need to find the appropriate CPAN library for video and audio files.

HTH,

David

Re: Next Steps for Bricolage Development [ In reply to ]

david at kineticode

May 17, 2010, 11:18 AM

Post #10 of 32 (12591 views)

On May 17, 2010, at 10:19 AM, Alex Krohn wrote:

>> There is some work on it in this fork/branch:
>>
>> http://github.com/brewt/bricolage/tree/dev_inline_edit.
>
> This is live for WHO and could get merged in.

I'll have to have a look at the diff.

>> http://github.com/brewt/bricolage/commits/dev_who_word_import
>>
>> Adrian, you around? What's the status of these?
>
> This is waiting on WHO still. It's beta stage and useful if anyone wants
> to give it a try, but will take some work probably.

What does it do, exactly? And what is it supposed to do, if it were no longer beta?

> Yikes, definitely not worth it. You might see minor perf gains on a
> windows platform where proc creation is expensive, but you would not see
> anything noticable on a linux platform, and probably have to fight a ton
> of bugs. For an application like Bricolage, this is really not that
> important (does not need very high concurency or lots of very fast, very
> short requests).

That was my impression, as well.

Best,

David

Re: Next Steps for Bricolage Development [ In reply to ]

bret at pectopah

May 17, 2010, 12:03 PM

Post #11 of 32 (12603 views)

Awesome, thanks.

> Make sense? I imagine that this is just a few hours work, plus tests, and whatever time you need to find the appropriate CPAN library for video and audio files.

Mostly. I have some learning to do about writing tests, so "hours" is
probably on the thin side. But I'm looking forward to taking it on.

Cheers,

Bret

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

Re: Next Steps for Bricolage Development [ In reply to ]

david at kineticode

May 17, 2010, 12:14 PM

Post #12 of 32 (12594 views)

On May 17, 2010, at 12:03 PM, Bret Dawson wrote:

> Awesome, thanks.
>
>> Make sense? I imagine that this is just a few hours work, plus tests, and whatever time you need to find the appropriate CPAN library for video and audio files.
>
> Mostly. I have some learning to do about writing tests, so "hours" is
> probably on the thin side. But I'm looking forward to taking it on.

Learning more about testing is time well spent, IMNSHO.

Best,

David

Re: Next Steps for Bricolage Development [ In reply to ]

alex at gossamer-threads

May 17, 2010, 12:39 PM

Post #13 of 32 (12595 views)

Hi David,

On Mon May 17 11:18:02, David E. Wheeler wrote:

> >> http://github.com/brewt/bricolage/commits/dev_who_word_import
> >>
> >> Adrian, you around? What's the status of these?
> >
> > This is waiting on WHO still. It's beta stage and useful if anyone wants
> > to give it a try, but will take some work probably.
>
> What does it do, exactly? And what is it supposed to do, if it were no longer beta?

It modifies the new story screen and allows you to upload a word file.
It then parses the word file per a pre-defined stylesheet mapping, and
pre fills out the story.

i.e. workflow is a user hits add story, hits upload, and then sees the
contents of his word file broken down into story elements.

Requires the user to use a specific word template and maintains a
mapping of word styles to bric elements. Works on basic elements like
paragraphs and lists and a few others, but isn't advanaced enough for
images/media.

My recolleciton is it all works, but would need effort to test and
generalize a bit more.

Cheers,

Alex

--
Alex Krohn <alex@gossamer-threads.com>

Re: Next Steps for Bricolage Development [ In reply to ]

david at kineticode

May 17, 2010, 1:07 PM

Post #14 of 32 (12597 views)

On May 17, 2010, at 12:39 PM, Alex Krohn wrote:

> It modifies the new story screen and allows you to upload a word file.
> It then parses the word file per a pre-defined stylesheet mapping, and
> pre fills out the story.
>
> i.e. workflow is a user hits add story, hits upload, and then sees the
> contents of his word file broken down into story elements.
>
> Requires the user to use a specific word template and maintains a
> mapping of word styles to bric elements. Works on basic elements like
> paragraphs and lists and a few others, but isn't advanaced enough for
> images/media.
>
> My recolleciton is it all works, but would need effort to test and
> generalize a bit more.

I'm hard-pressed to see how it could be generalized at all, outside of requiring:

a) A very specific element type hierarchy
b) A very specific Word document template

But perhaps I'm missing something?

Best,

David

Re: Next Steps for Bricolage Development [ In reply to ]

May 17, 2010, 1:07 PM

Post #15 of 32 (12596 views)

On Monday, May 17, 2010, at 01:19PM, "Alex Krohn" <alex@gossamer-threads.com> wrote:
>Yikes, definitely not worth it. You might see minor perf gains on a
>windows platform where proc creation is expensive, but you would not see
>anything noticable on a linux platform, and probably have to fight a ton
>of bugs. For an application like Bricolage, this is really not that
>important (does not need very high concurency or lots of very fast, very
>short requests).

Ok, then, let's leave that one alone.

OTOH, Alex's last sentence reminded me about the discussion we had back in January on big Bric installs and potential scalability enhancements to bric_queued.

http://www.gossamer-threads.com/lists/bricolage/users/38225#38225

If I can get the css scope down to something nice and manageable, that would also be something I would be willing to take on.

-Matt

Re: Next Steps for Bricolage Development [ In reply to ]

alex at gossamer-threads

May 17, 2010, 1:12 PM

Post #16 of 32 (12596 views)

Hi David,

On Mon May 17 01:07:07, David E. Wheeler wrote:

> I'm hard-pressed to see how it could be generalized at all, outside of requiring:
>
> a) A very specific element type hierarchy
> b) A very specific Word document template
>
> But perhaps I'm missing something?

No, you are pretty much right on.

The use case for WHO was the large number of content providers who did
not have access to Bric, they could take a WHO stylesheet, and provide
the content and translations of that content in word files, and would
greatly simplify the web teams job of loading content into Bric.

So I'm not sure it could be something added to core, unless a full UI
for managing the mappings was developed, and some msword deps added, but
might be useful living in contrib to anyone out there with a similar
problem.

Cheers,

Alex

--
Alex Krohn <alex@gossamer-threads.com>

Re: Next Steps for Bricolage Development [ In reply to ]

May 17, 2010, 1:14 PM

Post #17 of 32 (12595 views)

On Monday, May 17, 2010, at 04:07PM, "David E. Wheeler" <david@kineticode.com> wrote:
>On May 17, 2010, at 12:39 PM, Alex Krohn wrote:
>
>> It modifies the new story screen and allows you to upload a word file.
>> It then parses the word file per a pre-defined stylesheet mapping, and
>> pre fills out the story.
>
>I'm hard-pressed to see how it could be generalized at all, outside of requiring:
>
>a) A very specific element type hierarchy
>b) A very specific Word document template
>
>But perhaps I'm missing something?

Yes, but IMHO, even having the ability to do this sort of thing within those constraints would be an amazingly huge win from the workflow perspective. It would solve a problem I constantly deal with, namely, how to move stuff from the word documents everyone uses without end onto the web. If there were a preference panel where an admin could set up various element structures for Word doc importation, that would be even more awesome.

-Matt

Re: Next Steps for Bricolage Development [ In reply to ]

bret at pectopah

May 17, 2010, 1:49 PM

Post #18 of 32 (12602 views)

Actually, I think this is how it's done everywhere that Word is used as
a CMS input method. Either you have highly-structured Word templates, or
you have your import mechanism ignores everything that's not a standard
header or a paragraph.

But Matt's right: there's a big appetite for this out there, so even
having it in contrib (or in the template wiki) would be super useful.

Cheers,

Bret

On Mon, 2010-05-17 at 16:14 -0400, Matthew Rolf wrote:

> >I'm hard-pressed to see how it could be generalized at all, outside of requiring:
> >
> >a) A very specific element type hierarchy
> >b) A very specific Word document template
> >
> >But perhaps I'm missing something?
>
> Yes, but IMHO, even having the ability to do this sort of thing within those constraints would be an amazingly huge win from the workflow perspective. It would solve a problem I constantly deal with, namely, how to move stuff from the word documents everyone uses without end onto the web. If there were a preference panel where an admin could set up various element structures for Word doc importation, that would be even more awesome.
>
> -Matt
>

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

Re: Next Steps for Bricolage Development [ In reply to ]

bch at methodlogic

May 17, 2010, 2:18 PM

Post #19 of 32 (12585 views)

On Mon, May 17, 2010 at 12:14:49PM -0700, David E. Wheeler wrote:
> On May 17, 2010, at 12:03 PM, Bret Dawson wrote:
>
> > Awesome, thanks.
> >
> >> Make sense? I imagine that this is just a few hours work, plus tests, and whatever time you need to find the appropriate CPAN library for video and audio files.
> >
> > Mostly. I have some learning to do about writing tests, so "hours" is
> > probably on the thin side. But I'm looking forward to taking it on.
>
> Learning more about testing is time well spent, IMNSHO.

Seconded, fwiw.

> Best,
>
> David
>
>

--
Brad Harder
Method Logic Digital Consulting
http://methodlogic.net
http://twitter.com/bcharder

Re: Next Steps for Bricolage Development [ In reply to ]

bch at methodlogic

May 17, 2010, 2:20 PM

Post #20 of 32 (12600 views)

On Mon, May 17, 2010 at 04:49:18PM -0400, Bret Dawson wrote:
> Actually, I think this is how it's done everywhere that Word is used as
> a CMS input method. Either you have highly-structured Word templates, or
> you have your import mechanism ignores everything that's not a standard
> header or a paragraph.
>
> But Matt's right: there's a big appetite for this out there, so even
> having it in contrib (or in the template wiki) would be super useful.

This is pretty interesting; Can somebody supply a simple .doc illustrating
what's expected to be used as input?

Cheers,

-bch

> Cheers,
>
> Bret
>
>
> On Mon, 2010-05-17 at 16:14 -0400, Matthew Rolf wrote:
>
> > >I'm hard-pressed to see how it could be generalized at all, outside of requiring:
> > >
> > >a) A very specific element type hierarchy
> > >b) A very specific Word document template
> > >
> > >But perhaps I'm missing something?
> >
> > Yes, but IMHO, even having the ability to do this sort of thing within those constraints would be an amazingly huge win from the workflow perspective. It would solve a problem I constantly deal with, namely, how to move stuff from the word documents everyone uses without end onto the web. If there were a preference panel where an admin could set up various element structures for Word doc importation, that would be even more awesome.
> >
> > -Matt
> >
>
>
> --
> Bret Dawson
> Producer
> Pectopah Productions Inc.
> (416) 895-7635
> bret@pectopah.com
> www.pectopah.com
>

--
Brad Harder
Method Logic Digital Consulting
http://methodlogic.net
http://twitter.com/bcharder

Re: Next Steps for Bricolage Development [ In reply to ]

alex at gossamer-threads

May 17, 2010, 2:25 PM

Post #21 of 32 (12594 views)

Hi Brad,

On Mon May 17 04:07:35, bch wrote:

> On Mon, May 17, 2010 at 04:49:18PM -0400, Bret Dawson wrote:
> > Actually, I think this is how it's done everywhere that Word is used as
> > a CMS input method. Either you have highly-structured Word templates, or
> > you have your import mechanism ignores everything that's not a standard
> > header or a paragraph.
> >
> > But Matt's right: there's a big appetite for this out there, so even
> > having it in contrib (or in the template wiki) would be super useful.
>
> This is pretty interesting; Can somebody supply a simple .doc illustrating
> what's expected to be used as input?

Have a look at:

http://github.com/brewt/bricolage/blob/dev_who_word_import/conf/word_import.conf

for how the mapping is done (maps word styles to pod). As you can see,
it's non trivial to setup, but then neither is creating your element
hierarchy.

As for a sample word doc, I'll see if Adrian has a test one we were
using.

The deps for this are:

abiword (http://www.abisource.com/)
wvSummary (http://wvware.sourceforge.net/)
XML::Parser
Digest::MD5
File::Type
IPC::Open3
Storable

Cheers,

Alex

--
Alex Krohn <alex@gossamer-threads.com>

Re: Next Steps for Bricolage Development [ In reply to ]

May 17, 2010, 8:51 PM

Post #22 of 32 (12584 views)

Thanks for this Alex.

And while I'm dumping random enhancements into the dev list, does anyone have an objection to adding some sort of javascript "select all check boxes" feature for the bulk publish and asset search result screens? This seems like the sort of thing that should have been added a while ago. See this thread:

http://www.gossamer-threads.com/lists/bricolage/users/32617

-Matt

On May 17, 2010, at 5:25 PM, Alex Krohn wrote:

> Hi Brad,
>
> On Mon May 17 04:07:35, bch wrote:
>
>> On Mon, May 17, 2010 at 04:49:18PM -0400, Bret Dawson wrote:
>>> Actually, I think this is how it's done everywhere that Word is used as
>>> a CMS input method. Either you have highly-structured Word templates, or
>>> you have your import mechanism ignores everything that's not a standard
>>> header or a paragraph.
>>>
>>> But Matt's right: there's a big appetite for this out there, so even
>>> having it in contrib (or in the template wiki) would be super useful.
>>
>> This is pretty interesting; Can somebody supply a simple .doc illustrating
>> what's expected to be used as input?
>
> Have a look at:
>
> http://github.com/brewt/bricolage/blob/dev_who_word_import/conf/word_import.conf
>
> for how the mapping is done (maps word styles to pod). As you can see,
> it's non trivial to setup, but then neither is creating your element
> hierarchy.
>
> As for a sample word doc, I'll see if Adrian has a test one we were
> using.
>
> The deps for this are:
>
> abiword (http://www.abisource.com/)
> wvSummary (http://wvware.sourceforge.net/)
> XML::Parser
> Digest::MD5
> File::Type
> IPC::Open3
> Storable
>
> Cheers,
>
> Alex
>
> --
> Alex Krohn <alex@gossamer-threads.com>
>

Re: Next Steps for Bricolage Development [ In reply to ]

fulekia at denison

May 18, 2010, 10:39 AM

Post #23 of 32 (12589 views)

On May 17, 2010, at 4:49 PM, Bret Dawson wrote:
> But Matt's right: there's a big appetite for this out there, so even
> having it in contrib (or in the template wiki) would be super useful.

Totally. I spent a lot of time thinking about the UX workflow for
this last fall, in regards to the "Import OpenOffice documents through
SOAP" ticket: http://bricolage.lighthouseapp.com/projects/29601/tickets/16

Unfortunately I can't find my notes right now, but my thought was to
create a mapping process for importing/exporting XML or other
structured data, to avoid the "rigid" structure problems David alluded
to earlier. The use case I imagined was XML-oriented (OpenOffice,
DocBook, RSS/Atom), but something more generic would be awesome.

Some thoughts on the components needed in a possible import/export
scenario:

1) A bricolage object that describes an external data element (Word
Style, XML element), its occurrence specifications, what it contains,
etc.
2) A bricolage object that describes an external document type,
mapping its data elements to bricolage elements/each other, and
default/exception behaviors (e.g., ignore/die/use default value if
element X is missing).
3) A method for creating, importing or referencing the element maps
(create one in the UI, import them via SOAP, etc.).
4) A method for pushing content through the mapping filters (import
word document, export RSS, etc.)
5) Job types for scheduling import/export jobs.

Once you've done a couple of import filters, #1 would yield a pretty
decent standard vocabulary of data elements, which might not be a bad
thing to include in bricolage. I know we're all about the document
modeling, which is very important, but a standard element vocab would
help novice users a lot, I think.

-Aaron

---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------

Re: Next Steps for Bricolage Development [ In reply to ]

fulekia at denison

May 18, 2010, 10:42 AM

Post #24 of 32 (12578 views)

On May 15, 2010, at 11:47 PM, David E. Wheeler wrote:

> But I also wouldn't mind seeing someone pick up input channels,
> which Marshall did a lot of work on in 2005. I think it just needed
> UI work. The back end would likely need quite a bit of updating, of
> course. Branch:
>
> http://github.com/bricoleurs/bricolage/tree/dev_ics

I just started reading through the diffs, but for those of us who
aren't bric/perl ninjas, how exactly did input channels work?

-Aaron

---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------

Re: Next Steps for Bricolage Development [ In reply to ]

phillip at communitybandwidth

May 19, 2010, 8:24 AM

Post #25 of 32 (12567 views)

On 2010-05-17, at 11:51 PM, Matthew Rolf wrote:

> Thanks for this Alex.
>
> And while I'm dumping random enhancements into the dev list, does anyone have an objection to adding some sort of javascript "select all check boxes" feature for the bulk publish and asset search result screens? This seems like the sort of thing that should have been added a while ago. See this thread:
>
> http://www.gossamer-threads.com/lists/bricolage/users/32617

+1

Think I opened a related "enhancement" ticket here:
http://bricolage.lighthouseapp.com/projects/29601/tickets/116-bulk-actions-option-for-my-workspace

Phillip.

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com