Gzip Action

Hello,

I have need of a Gzip Action.  I see it alluded to in the 
Bric:ist::Act
ion docs, but maybe more as an example.  Before I go and 
write one, does it already exist, or has somebody written
one?

Thanks,

John

On Fri, 25 May 2007, johngrumpet.net wrote:
> I have need of a Gzip Action.  I see it alluded to in
the Bric:ist::Act
ion 
> docs, but maybe more as an example.  Before I go and
write one, does it 
> already exist, or has somebody written one?

I guess not.
It think it's a little weird/sad that there aren't
more dist actions. They're simple to write,
well documented (assuming you know to look in Bric:ist::Act
ion)
and potentially really useful and easy to use.
I wonder why there aren't more.

(A tangent is again this blog from David:
http://www.justatheory.com/bricolage/design/t
asks_jobs_actions.html
)

Something we've recently noticed is that when there are a
lot of  
items on a desk (150 <)  browser performance begins to
degrade when  
you load that desk.  At about 400-500 items per desk browser
 
performance is significantly impaired in some instances -
long load  
times, poor interface responsiveness with regard to the drop
downs  
and checkboxes.

By far the worst offender is Firefox on the Mac platform -
both PPC  
and Intel.  Internet Explorer 7 also seems to have issues,
although  
perhaps not as severe.  Both browsers will peg the processor
for up  
to 10-15 seconds.  IE 6 is more or less usable - still a
delay, but  
it gets the job done.  Interestingly, the best browser is
Safari 2.   
It shows almost no performance degredation, even with almost
700  
items on a desk.  Intel Safari is faster than PPC, and the
nightly  
webkit is faster yet.

Also, the server barely breaks a sweat when FF makes the
request.   
The bottleneck truly is on the client.  Not saying that
there isn't  
something that could be optimized in the delivery to make it
better,  
just that the Apache/Postgres combo is humming along without
a problem.

At any rate, I just wanted to pass that along and see if
anyone else  
has looked into it.  Regardig Firefox, I'm not sure if it is
a div  
rendering issue or what.  Anyone have any ideas?

Thanks,

Matt

When you create a related media file within a document, it
looks like  
that newly created media gets dropped on the first desk and
workflow  
it can find that is available to the user.  Something like
that  is  
not good if the user is working in their third workflow and
the media  
gets dropped into the first one.  Can one of the more
experienced  
developers confirm if that behavior is actually the default,
and  
where we might go to change it?  Ideally, we'd like the
newly created  
media to get plopped down on the same desk that the story is
on.   
We're guessing this is something that is set within the app
itself,  
and not a template issue.

Thanks,

Matt

Matt Rolf wrote:
> When you create a related media file within a document,
it looks like 
> that newly created media gets dropped on the first desk
and workflow it 
> can find that is available to the user.  Something like
that  is not 
> good if the user is working in their third workflow and
the media gets 
> dropped into the first one.  Can one of the more
experienced developers 
> confirm if that behavior is actually the default, and
where we might go 
> to change it?  Ideally, we'd like the newly created
media to get plopped 
> down on the same desk that the story is on.  We're
guessing this is 
> something that is set within the app itself, and not a
template issue.

Hi,

I've actually noticed that myself today when using bric_soap
to create a 
  new media file. It gets dropped on the first desk of the
first 
workflow it finds (looks like alphabetical). I can't see a
bric_soap 
option to set the creation workflow, obviously you can move
it once 
created but that's not quite the point.

The problem is that you'll need to make sure the desk that
the story is 
on is also a media desk and find the media workflow for that
desk 
(rather than the story workflow).

the upload widget is comp/widgets/profile/media_upload.mc

and you'll need something like

$media->set_workflow_id( $w_ID );
$media->set_current_desk($desk_object);

from http://www.bricolage.cc/docs/1.10/api/Bric::Biz::Asset


regards,

Paul

On Thu, 31 May 2007, Matt Rolf wrote:
> Something we've recently noticed is that when there are
a lot of items on a 
> desk (150 <)  browser performance begins to degrade
when you load that desk. 
> At about 400-500 items per desk browser performance is
significantly impaired 
> in some instances - long load times, poor interface
responsiveness with 
> regard to the drop downs and checkboxes.

You can turn on paging in Preferences. We have 30 per page.


>   Regardig Firefox, I'm not sure if it is a div
rendering 
> issue or what.  Anyone have any ideas?

Not me.

On Thu, 31 May 2007, Paul Orrock wrote:
> I've actually noticed that myself today when using
bric_soap to create a  new
> media file. It gets dropped on the first desk of the
first workflow it finds
> (looks like alphabetical). I can't see a bric_soap
option to set the creation
> workflow, obviously you can move it once created but
that's not quite the
> point.

  --desk    - required desk option for move command;
optional for
              create and update commands

  --workflow    - workflow option for move, create, and
update commands

Scott Lanning wrote:
>  --desk    - required desk option for move command;
optional for
>              create and update commands
> 
>  --workflow    - workflow option for move, create, and
update commands

Oh the old read the documentation properly trick !!! Cunning


regards,

Paul.

Thanks.  For us, our desks are shared between the media and
story  
workflows, so this should work.  We'll give it a whirl and
see what  
we come up with.

-Matt

On May 31, 2007, at 12:37 PM, Paul Orrock wrote:

> Matt Rolf wrote:
>> When you create a related media file within a
document, it looks  
>> like that newly created media gets dropped on the
first desk and  
>> workflow it can find that is available to the user.
 Something  
>> like that  is not good if the user is working in
their third  
>> workflow and the media gets dropped into the first
one.  Can one  
>> of the more experienced developers confirm if that
behavior is  
>> actually the default, and where we might go to
change it?   
>> Ideally, we'd like the newly created media to get
plopped down on  
>> the same desk that the story is on.  We're guessing
this is  
>> something that is set within the app itself, and
not a template  
>> issue.
>
> Hi,
>
> I've actually noticed that myself today when using
bric_soap to  
> create a  new media file. It gets dropped on the first
desk of the  
> first workflow it finds (looks like alphabetical). I
can't see a  
> bric_soap option to set the creation workflow,
obviously you can  
> move it once created but that's not quite the point.
>
> The problem is that you'll need to make sure the desk
that the  
> story is on is also a media desk and find the media
workflow for  
> that desk (rather than the story workflow).
>
> the upload widget is
comp/widgets/profile/media_upload.mc
>
> and you'll need something like
>
> $media->set_workflow_id( $w_ID );
> $media->set_current_desk($desk_object);
>
> from http://www.bricolage.cc/docs/1.10/api/Bric::Biz::Asset

>
> regards,
>
> Paul

Looks like Xinha is finally out of nightly builds and into
general  
releases.

ht
tp://xinha.python-hosting.com/wiki/DownloadsPage

0.931 didn't seem to play nicely with Bricolage 10.2 . 
Anyone else  
upgraded?

-Matt