|
List Info
Thread: Xinha
|
|
| Xinha |
|
2006-10-25 00:21:50 |
Hi Dawn.
Oh dear. The short answer is that yes, the spellchecker
works great in
our 1.10.1 installation. But I'm afraid I did a bad job of
documenting
the necessary tweaks, and I'm going to have to do some
digging before I
have a useful answer for you.
Embarrassed,
Bret
Dawn Buie wrote:
> Hi Bret- I've found that I can't turn off the Xinha
spellchecker from
> bricolage.conf
>
> As well the spellchecker doesn't work.
>
> Did you remove yours or make spell checker work?
>
> thanks
> Dawn
>
> Begin forwarded message:
>
>> From: Bret Dawson <bret pectopah.com>
>> Date: June 25, 2005 2:43:15 PM PDT (CA)
>> To: Serge Sozonoff <sergesozonoff.com>
>> Cc: Marshall Roch <marshallexclupen.com>, bricolage-devel
>> <devellists.bricolage.cc>
>> Subject: Re: Xinha
>>
>> Hi again.
>>
>> Yes, the toolbar worked just fine (except for the
aforementioned
>> spellchecker), although Xinha offers a larger
button set than
>> HTMLArea, so probably the list of choices in
bricolage.conf ought to
>> be updated. (We'll do this this week and send a
patch. Marshall, does
>> your work in the already deal with the
spellchacker?)
>>
>> As for the drop-in, no, I didn't change any
Bricolage files at all. I
>> just unzipped Xinha into /comp/media, and then
changed the name of
>> the Xinha directory to "htmlarea".
>>
>> Hope this helps,
>>
>> Bret
>>
>>
>>
>> Serge Sozonoff wrote:
>>
>>> Hi Bret,
>>>
>>>> Xinha actually works as a straight drop-in
in 1.8.5, except for the
>>>> spellchecker. Was that a beast, Marshall?
>>>
>>> When you say its "drop-in" how drop
in is that exactly 
>>> Because I sure can't get it to work as a
straigh drop-in.
>>> Did you make changes to any bricolage files to
get it to work?
>>> Thanks,
>>> Serge
>>
>>
>>
>> --
>> Bret Dawson
>> Producer
>> Pectopah Productions Inc.
>> (416) 895-7635
>> bretpectopah.com
>> www.pectopah.com
>>
>
>
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bretpectopah.com
www.pectopah.com
|
|
| Autohandlers |
|
2006-10-24 16:18:31 |
On Oct 24, 2006, at 08:34, Matt Rolf wrote:
> Just so I'm clear as to how autohandlers work, would it
be ok to
> have the autohandler call an element from the page
template so it
> gets rendered outside the <html> tag? Or is that
something that
> would violate the integrity of the autohandler/page
template
> relationship?
I wouldn't recommend it, but this is what Mason-style
inheritance is
for. For example for one of our customers, we have this code
in the
autohandler:
<head>
<title>foo</title>
<& SELF:.rss &>
</head>
%# ...
<%method .rss>
</%method>
Then, in the home page template, we have:
<%method .rss>
<link rel="alternate"
type="application/rss+xml" title="RSS
Feed" href="rss.xml" />
</%method>
While in the cover page template, we have:
<%method .rss>
<link rel="alternate"
type="application/rss+xml" title="<%
$title %> RSS Feed" href="<% $rss_url
%>" />
</%method>
So when you publish the home page, it gets one value from
the .rss
method, when you publish the cover, it gets another, and if
other
story types are published for which their templates have no
.rss
method, it defaults to the blank method in autohandler.
But this only works for story type templates. Methods
created in
subelement templates will be ignored; they're not in the
template
inheritance path.
> Another question our programmer brought up was whether
we might be
> able to abstract the autohandler and/or category
templates to be
> more logic oriented. For example, it would look at the
story
> template being called, and follow a different rendering
path based
> on the story type. Can anyone offer feedback on the
feasibility of
> that solution?
Well, that's what story type templates are for!
Best,
David
|
|
| Autohandlers |
|
2006-10-24 16:11:13 |
Matt Rolf wrote:
> Our office programmer is working on using Bricolage to
develop a php
> application within the realm of our normal web site.
On the outputted
> pages, he needs to open up sessions for users of the
application prior
> to the html headers being passed to a browser. Right
now our site
> autohandler sets the <html> tag and the page
template puts all its
> elements within that tag.
>
> Just so I'm clear as to how autohandlers work, would it
be ok to have
> the autohandler call an element from the page template
so it gets
> rendered outside the <html> tag? Or is that
something that would
> violate the integrity of the autohandler/page template
relationship?
Yes. We fill in plenty of stuff prior to the <html>
tag, you could put
in some PHP header calls before doing anything else, based
on the story
type for example.
> Another question our programmer brought up was whether
we might be able
> to abstract the autohandler and/or category templates
to be more logic
> oriented. For example, it would look at the story
template being
> called, and follow a different rendering path based on
the story type.
> Can anyone offer feedback on the feasibility of that
solution?
>
We do this kind of thing and it works great. We use it to
pull in
different navigation bars based on what category we are in
on the site.
- cameron
|
|
| Autohandlers |
|
2006-10-24 19:13:43 |
cdmiller wrote:
> Matt Rolf wrote:
>> Our office programmer is working on using Bricolage
to develop a php
>> application within the realm of our normal web
site. On the outputted
>> pages, he needs to open up sessions for users of
the application prior
>> to the html headers being passed to a browser.
Right now our site
>> autohandler sets the <html> tag and the page
template puts all its
>> elements within that tag.
>>
>> Just so I'm clear as to how autohandlers work,
would it be ok to have
>> the autohandler call an element from the page
template so it gets
>> rendered outside the <html> tag? Or is that
something that would
>> violate the integrity of the autohandler/page
template relationship?
>
> Yes. We fill in plenty of stuff prior to the
<html> tag, you could put
> in some PHP header calls before doing anything else,
based on the story
> type for example.
>
Slight correction (just checked our main autohandler): In
our main
autohandler we only add the doctype outside of the
<html>, we do grab
some story elements and do stuff based on story type but
thats all
rendered within <html>. For a special case (different
OC) we are
messing with rendering some php calls before the
<html> tag, for header
cookie getting and setting calls.
- cameron
|
|
| New Development Release? |
|
2006-11-30 17:07:50 |
On Nov 29, 2006, at 10:24, Matt Rolf wrote:
> Does anyone know when the development release promised
for the fall
> will be out?
I've been waiting for Marshall to get to merge in his
Ajaxification
Summer of Code branch.
Marshall? Got holidays coming up?
Best,
David
|
|
| Bulk Publish and Checked Out Files |
|
2006-12-05 19:13:46 |
On Dec 5, 2006, at 11:06, Matt Rolf wrote:
> Is there a way we can republish the last published
version of the
> document without checking it back in so the template
can take
> effect? Is this something best done via the SOAP
interface?
Bulk republish should do that for you. So should
bric_publish. For
SOAP, you'd have to use the --published-only option. What
version of
Bricolage are you using?
Best,
David
|
|
| Bulk Publish and Checked Out Files |
|
2006-12-05 19:35:18 |
1.10.2
>On Dec 5, 2006, at 11:06, Matt Rolf wrote:
>
>>Is there a way we can republish the last published
version of the
>>document without checking it back in so the template
can take
>>effect? Is this something best done via the SOAP
interface?
>
>Bulk republish should do that for you. So should
bric_publish. For
>SOAP, you'd have to use the --published-only option.
What version of
>Bricolage are you using?
>
>Best,
>
>David
--
Matt Rolf, J.D.
Web Technology Analyst
Computing Services
Denison University
(740) 587-6537
|
|
[1-7]
|
|