You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Matt Raible <mr...@gmail.com> on 2006/05/08 22:22:55 UTC

Prev and Next Entries

The current "prev and next" feature in 2.2 works, but it only ever
allows me to go back one entry at a time.  Ideally, I'd like to see
something like the following:

1. If the user is viewing more than one day (for example, the default
view with 15 entries), the "prev" link will take then to the previous
X number of entries (ideally X is the same number as is currently
shown).

2. If the user is viewing a particular day, "prev" takes them to the
previous day.  This one might be tricky since YYYYMMDD shows a
particular day at the top and previous days below it.  This one should
probably operate like #1.

3. When viewing a single entry, clicking "prev" navigates one entry at
a time. This might not even make sense as clicking "prev" and seeing
the previous entry at the top of a long list of entries is desireable.

Thoughts?  Is this already implemented as part of 2.3?

Also, I'd like to contribute a version of my new theme to Roller. 
Should I simple check it into "themes" or should it go into the
support project?

Thanks,

Matt

Re: Prev and Next Entries

Posted by Allen Gilliland <al...@sun.com>.

Matt Raible wrote:
> Correct me if I'm wrong, but aren't we still in a situation where
> removing themes will break people's blogs during an upgrade?

sort of.  we just need to tell people that moving forward they need to 
grab the themes and add them manually.

we should probably add a little logic in to allow for a default theme 
which is used in the event that a user has chosen a theme that doesn't 
exist anymore.


> 
> If so, we should find a way to solve this and ship Roller with only
> 2-3 (or even just 1) good-looking, standards-compliant themes.  Then
> figure out a way to grow a community around producing themes like
> Wordpress has done.

absolutely.  we definitely need at least 1 good theme in the 
distribution and i think it's fine to have a few.  the real goal is 
definitely to get the community involved in creating and maintaining themes.

-- Allen


> 
> Matt
> 
> On 5/8/06, Allen Gilliland <al...@sun.com> wrote:
>>
>> >
>> >> Also, I'd like to contribute a version of my new theme to Roller.
>> >> Should I simple check it into "themes" or should it go into the
>> >> support project?
>> >
>> > If the new theme does not use LGPL, then I'd vote for Roller "themes"
>>
>> Actually, I vote for support project.  Unless this is going to be one of
>> the few themes that we ship with the default Roller package.
>>
>> -- Allen
>>
>>
>> >
>> > - Dave
>> >
>>

Re: Prev and Next Entries

Posted by Allen Gilliland <al...@sun.com>.

David M Johnson wrote:
> 
> On May 9, 2006, at 1:25 AM, Brian Blakeley wrote:
>> Ok, then I am glad that I was not barking up the wrong tree on this
>> matter.
>>
>> So, what makes sense to me is that a set of macros needs to be developed
>> that either produces no html or that produces an xhtml framework that
>> the theme's CSS can style in a Zen Garden sort of way.
>>
>> I think I like the second approach, but Allen's insights about MT are
>> probably more helpful than my thinking.
>>
>> What I would like to see is that #showBlogroll producing a basic xhtml
>> structure such as:
>>
>> <ul class="level1">
>>    <li>Blogroll</li>
>>        <ul class="level2">
>>           <li><a href="">Dave Johnson</a></li>
>>           <li><a href="">Matt Raible</a></li>
>>           ...
>>        </ul>
>>    <li>News</li>
>>        <ul class ="level2">
>>           <li><a href="">Che Nuke</a></li>
>>           <li><a href="">LabourStart</a></li>
>>           ...
>>        </ul>
>>    ...
>> </ul>
>>
>> The user could then wrap this xhtml in a nice <div></div> of there
>> design and be on their way.
> 
> Yes. That would be *much* better.

I agree, that looks like a good way to do it.  My one change would be to 
use class names that a bit more relevant.  "level1" and "level2" just 
have no meaning.

Another thing to check on is microformats.  I'm not sure if there is 
anything for blogrolls, but it's worth a look.

> 
> 
>> Although, this would lead into a discussion of class attributes, etc, so
>> I can see the value in Allen's suggestion that no html be produced from
>> the macro starting to make some solid sense.
> 
> My position is that macros are needed for code re-use, which is most 
> definitely a good thing. However, I do agree that we went too far in 
> creating macros for each and every little thing.

This is also my stance.  I am not against *all* use of macros, I just 
think that we need to be very careful about what new macros we add 
moving forward.  I believe we have already got ourselves into a position 
where there are too many bad macros and now we have to continue 
supporting them indefinitely.

-- Allen


> 
> - Dave
> 
> 

Re: Prev and Next Entries

Posted by David M Johnson <Da...@Sun.COM>.
On May 9, 2006, at 1:25 AM, Brian Blakeley wrote:
> Ok, then I am glad that I was not barking up the wrong tree on this
> matter.
>
> So, what makes sense to me is that a set of macros needs to be  
> developed
> that either produces no html or that produces an xhtml framework that
> the theme's CSS can style in a Zen Garden sort of way.
>
> I think I like the second approach, but Allen's insights about MT are
> probably more helpful than my thinking.
>
> What I would like to see is that #showBlogroll producing a basic xhtml
> structure such as:
>
> <ul class="level1">
>    <li>Blogroll</li>
>        <ul class="level2">
>           <li><a href="">Dave Johnson</a></li>
>           <li><a href="">Matt Raible</a></li>
>           ...
>        </ul>
>    <li>News</li>
>        <ul class ="level2">
>           <li><a href="">Che Nuke</a></li>
>           <li><a href="">LabourStart</a></li>
>           ...
>        </ul>
>    ...
> </ul>
>
> The user could then wrap this xhtml in a nice <div></div> of there
> design and be on their way.

Yes. That would be *much* better.


> Although, this would lead into a discussion of class attributes,  
> etc, so
> I can see the value in Allen's suggestion that no html be produced  
> from
> the macro starting to make some solid sense.

My position is that macros are needed for code re-use, which is most  
definitely a good thing. However, I do agree that we went too far in  
creating macros for each and every little thing.

- Dave



Re: Prev and Next Entries

Posted by Brian Blakeley <we...@labourunions.com>.
Ok, then I am glad that I was not barking up the wrong tree on this
matter.

So, what makes sense to me is that a set of macros needs to be developed
that either produces no html or that produces an xhtml framework that
the theme's CSS can style in a Zen Garden sort of way.

I think I like the second approach, but Allen's insights about MT are
probably more helpful than my thinking.

What I would like to see is that #showBlogroll producing a basic xhtml
structure such as:

<ul class="level1">
   <li>Blogroll</li>
       <ul class="level2">
          <li><a href="">Dave Johnson</a></li>
          <li><a href="">Matt Raible</a></li>
          ...
       </ul>
   <li>News</li>
       <ul class ="level2">
          <li><a href="">Che Nuke</a></li>
          <li><a href="">LabourStart</a></li>
          ...
       </ul>
   ...
</ul>

The user could then wrap this xhtml in a nice <div></div> of there
design and be on their way.

Although, this would lead into a discussion of class attributes, etc, so
I can see the value in Allen's suggestion that no html be produced from
the macro starting to make some solid sense.

In that case I guess we would be arriving at a templating situation.

I should add that I would like to be of some assistance on this and,
although I am by no means a java programmer, I would be eager to lend a
hand in some way.


Brian



On Mon, 2006-05-08 at 20:43 -0700, Allen Gilliland wrote: 
> 
> Brian Blakeley wrote:
> > While, I am all for a smaller selection of high quality themes shipping
> > with Roller and the development of a third party themes farm-system, I
> > think this raises the opportunity for me to ask a question I have been
> > having.
> > 
> > I have been trying to develop a new theme that will knock your socks off
> > and I am having a major issue with the code produced by the velocity
> > macros.
> > 
> > Basically, the code produced by many of the macros [i.e. #showBlogroll()
> > and #showRSSLinks() ] is making the CSS for something I want to do
> > almost if not completely impossible.
> > 
> > If the proposal is to clamp down on "non-standards compatible" themes I
> > think the effort needs to be preceded with the development of a full set
> > of CSS friendly standards compliant macros.
> 
> yep, i am of the exact same opinion.  this is one of the reasons why i 
> am still lobbying against macros that produce html for users.  from my 
> experience with MT i don't remember them ever using macros that actually 
> write html for the user, the user always writes the html and inserts the 
> appropriate data where appropriate via variables, etc.
> 
> > 
> > I hope I am missing something with regard to the macros, but I don't
> > think so.
> 
> nope, you aren't missing anything =(
> 
> -- Allen
> 
> 
> > 
> > 
> > 
> > 
> >  
> > 
> > On Mon, 2006-05-08 at 20:52 -0400, Dave Johnson wrote:
> >> On May 8, 2006, at 5:52 PM, Matt Raible wrote:
> >>
> >>> Correct me if I'm wrong, but aren't we still in a situation where
> >>> removing themes will break people's blogs during an upgrade?
> >> You are correct. We have to keep the existing themes or we will break  
> >> existing users blogs.
> >>
> >> There are a number of themes that I would like to drop (I don't even  
> >> want to maintain them at Roller Support), but I believe the only way  
> >> we can do that now is to keep those themes in Roller but make it  
> >> impossible to choose them.
> >>
> >>
> >>> If so, we should find a way to solve this and ship Roller with only
> >>> 2-3 (or even just 1) good-looking, standards-compliant themes.  Then
> >>> figure out a way to grow a community around producing themes like
> >>> Wordpress has done.
> >> +1
> >>
> >> - Dave
> >>
> > 


Re: Prev and Next Entries

Posted by Allen Gilliland <al...@sun.com>.

Brian Blakeley wrote:
> While, I am all for a smaller selection of high quality themes shipping
> with Roller and the development of a third party themes farm-system, I
> think this raises the opportunity for me to ask a question I have been
> having.
> 
> I have been trying to develop a new theme that will knock your socks off
> and I am having a major issue with the code produced by the velocity
> macros.
> 
> Basically, the code produced by many of the macros [i.e. #showBlogroll()
> and #showRSSLinks() ] is making the CSS for something I want to do
> almost if not completely impossible.
> 
> If the proposal is to clamp down on "non-standards compatible" themes I
> think the effort needs to be preceded with the development of a full set
> of CSS friendly standards compliant macros.

yep, i am of the exact same opinion.  this is one of the reasons why i 
am still lobbying against macros that produce html for users.  from my 
experience with MT i don't remember them ever using macros that actually 
write html for the user, the user always writes the html and inserts the 
appropriate data where appropriate via variables, etc.

> 
> I hope I am missing something with regard to the macros, but I don't
> think so.

nope, you aren't missing anything =(

-- Allen


> 
> 
> 
> 
>  
> 
> On Mon, 2006-05-08 at 20:52 -0400, Dave Johnson wrote:
>> On May 8, 2006, at 5:52 PM, Matt Raible wrote:
>>
>>> Correct me if I'm wrong, but aren't we still in a situation where
>>> removing themes will break people's blogs during an upgrade?
>> You are correct. We have to keep the existing themes or we will break  
>> existing users blogs.
>>
>> There are a number of themes that I would like to drop (I don't even  
>> want to maintain them at Roller Support), but I believe the only way  
>> we can do that now is to keep those themes in Roller but make it  
>> impossible to choose them.
>>
>>
>>> If so, we should find a way to solve this and ship Roller with only
>>> 2-3 (or even just 1) good-looking, standards-compliant themes.  Then
>>> figure out a way to grow a community around producing themes like
>>> Wordpress has done.
>> +1
>>
>> - Dave
>>
> 

Re: Prev and Next Entries

Posted by Brian Blakeley <we...@labourunions.com>.
While, I am all for a smaller selection of high quality themes shipping
with Roller and the development of a third party themes farm-system, I
think this raises the opportunity for me to ask a question I have been
having.

I have been trying to develop a new theme that will knock your socks off
and I am having a major issue with the code produced by the velocity
macros.

Basically, the code produced by many of the macros [i.e. #showBlogroll()
and #showRSSLinks() ] is making the CSS for something I want to do
almost if not completely impossible.

If the proposal is to clamp down on "non-standards compatible" themes I
think the effort needs to be preceded with the development of a full set
of CSS friendly standards compliant macros.

I hope I am missing something with regard to the macros, but I don't
think so.




 

On Mon, 2006-05-08 at 20:52 -0400, Dave Johnson wrote:
> On May 8, 2006, at 5:52 PM, Matt Raible wrote:
> 
> > Correct me if I'm wrong, but aren't we still in a situation where
> > removing themes will break people's blogs during an upgrade?
> 
> You are correct. We have to keep the existing themes or we will break  
> existing users blogs.
> 
> There are a number of themes that I would like to drop (I don't even  
> want to maintain them at Roller Support), but I believe the only way  
> we can do that now is to keep those themes in Roller but make it  
> impossible to choose them.
> 
> 
> > If so, we should find a way to solve this and ship Roller with only
> > 2-3 (or even just 1) good-looking, standards-compliant themes.  Then
> > figure out a way to grow a community around producing themes like
> > Wordpress has done.
> 
> +1
> 
> - Dave
> 


Re: Prev and Next Entries

Posted by Dave Johnson <da...@rollerweblogger.org>.
On May 8, 2006, at 5:52 PM, Matt Raible wrote:

> Correct me if I'm wrong, but aren't we still in a situation where
> removing themes will break people's blogs during an upgrade?

You are correct. We have to keep the existing themes or we will break  
existing users blogs.

There are a number of themes that I would like to drop (I don't even  
want to maintain them at Roller Support), but I believe the only way  
we can do that now is to keep those themes in Roller but make it  
impossible to choose them.


> If so, we should find a way to solve this and ship Roller with only
> 2-3 (or even just 1) good-looking, standards-compliant themes.  Then
> figure out a way to grow a community around producing themes like
> Wordpress has done.

+1

- Dave


Re: Prev and Next Entries

Posted by Matt Raible <mr...@gmail.com>.
Correct me if I'm wrong, but aren't we still in a situation where
removing themes will break people's blogs during an upgrade?

If so, we should find a way to solve this and ship Roller with only
2-3 (or even just 1) good-looking, standards-compliant themes.  Then
figure out a way to grow a community around producing themes like
Wordpress has done.

Matt

On 5/8/06, Allen Gilliland <al...@sun.com> wrote:
>
> >
> >> Also, I'd like to contribute a version of my new theme to Roller.
> >> Should I simple check it into "themes" or should it go into the
> >> support project?
> >
> > If the new theme does not use LGPL, then I'd vote for Roller "themes"
>
> Actually, I vote for support project.  Unless this is going to be one of
> the few themes that we ship with the default Roller package.
>
> -- Allen
>
>
> >
> > - Dave
> >
>

Re: Prev and Next Entries

Posted by Matt Raible <mr...@gmail.com>.
On 5/11/06, David M Johnson <Da...@sun.com> wrote:
>
> On May 9, 2006, at 11:43 PM, Matt Raible wrote:
>
> > On 5/9/06, David M Johnson <Da...@sun.com> wrote:
> >>
> >> On May 9, 2006, at 7:34 PM, Matt Raible wrote:
> >> > I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
> >> > have noticed an issue with the LineBreak Plugin.  As soon as it's
> >> > added to an entry, the entry cannot be rendered and there's no
> >> way of
> >> > getting it back - even though it's stored in the database and
> >> renders
> >> > in the editor. Below is an example.
> >>
> >> What  do you mean by "no way of getting it back." You mean you can't
> >> even get it back when you uncheck the line-break plugin and
> >> republish?
>
> > Correct.
>
> That sounds pretty disturbing and I don't really understand how it
> could be happening. What Velocity code are you using in your day
> template to display entry content?

I figured out the issue - it was caused by weblog.vm and being a mix
of 2.2 and 2.3 - where I wasn't properly handling the new summary
stuff.  Short version: I was missing macros and such for 2.3.  Fixed
now.

Thanks,

Matt

>
>   - Dave
>
>
> >
> >>
> >> - Dave
> >>
> >>
> >>
> >>
>
>

Re: Prev and Next Entries

Posted by David M Johnson <Da...@Sun.COM>.
On May 9, 2006, at 11:43 PM, Matt Raible wrote:

> On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>>
>> On May 9, 2006, at 7:34 PM, Matt Raible wrote:
>> > I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
>> > have noticed an issue with the LineBreak Plugin.  As soon as it's
>> > added to an entry, the entry cannot be rendered and there's no  
>> way of
>> > getting it back - even though it's stored in the database and  
>> renders
>> > in the editor. Below is an example.
>>
>> What  do you mean by "no way of getting it back." You mean you can't
>> even get it back when you uncheck the line-break plugin and  
>> republish?

> Correct.

That sounds pretty disturbing and I don't really understand how it  
could be happening. What Velocity code are you using in your day  
template to display entry content?

  - Dave


>
>>
>> - Dave
>>
>>
>>
>>


Re: Prev and Next Entries

Posted by Allen Gilliland <al...@sun.com>.

Matt Raible wrote:
> On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>>
>> On May 9, 2006, at 7:34 PM, Matt Raible wrote:
>> > I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
>> > have noticed an issue with the LineBreak Plugin.  As soon as it's
>> > added to an entry, the entry cannot be rendered and there's no way of
>> > getting it back - even though it's stored in the database and renders
>> > in the editor. Below is an example.
>>
>> What  do you mean by "no way of getting it back." You mean you can't
>> even get it back when you uncheck the line-break plugin and republish?
> 
> Correct.

hrmm.  that's not a plugin problem, that sounds like something worse.

-- Allen


> 
>>
>> - Dave
>>
>>
>>
>>

Re: Prev and Next Entries

Posted by Matt Raible <mr...@gmail.com>.
On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>
> On May 9, 2006, at 7:34 PM, Matt Raible wrote:
> > I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
> > have noticed an issue with the LineBreak Plugin.  As soon as it's
> > added to an entry, the entry cannot be rendered and there's no way of
> > getting it back - even though it's stored in the database and renders
> > in the editor. Below is an example.
>
> What  do you mean by "no way of getting it back." You mean you can't
> even get it back when you uncheck the line-break plugin and republish?

Correct.

>
> - Dave
>
>
>
>

Re: Prev and Next Entries

Posted by David M Johnson <Da...@Sun.COM>.
On May 9, 2006, at 7:34 PM, Matt Raible wrote:
> I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
> have noticed an issue with the LineBreak Plugin.  As soon as it's
> added to an entry, the entry cannot be rendered and there's no way of
> getting it back - even though it's stored in the database and renders
> in the editor. Below is an example.

What  do you mean by "no way of getting it back." You mean you can't  
even get it back when you uncheck the line-break plugin and republish?

- Dave




Re: New comment macro(s) (was Re: Prev and Next Entries)

Posted by David M Johnson <Da...@Sun.COM>.
On May 9, 2006, at 10:21 PM, Matt Raible wrote:

> On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>>
>> On May 9, 2006, at 7:34 PM, Matt Raible wrote:
>> > On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>> >> On May 9, 2006, at 6:01 PM, Matt Raible wrote:
>> >> > My modifications to the *.vm templates fix JavaScript and CSS
>> >> issues -
>> >> > should those go in 2.3 or 2.4?
>> >> I've already found 1 problem in RC2, so they could conceivably  
>> go in
>> >> 2.3.
>> >> How extensive and how risky are those *.vm changes?
>> >
>> > I've attached the patch so you can see.  The only major thing is  
>> a new
>> > form for comments that more CSS-friendly. Other things include new
>> > macros and fixing comments HTML so it renders with XHTML
>> > compliance. I also fixed a bug in the JavaScript for Remember Me
>> > (only happens
>> > with IE).
>>
>> Hmmm... I think we should consider that for 2.4. However, I don't
>> like the idea of introducing another comment form macro. We already
>> have two (regular and twisty-style) and we should really have just
>> one. Can we change the existing comment form macro to make it CSS
>> compliant/friendly instead?
>
> Yes.  We can certainly do this.  However, it might be somewhat tedious
> to make sure it works across all the themes.  Should I enter a bug for
> it?  It'd be nice to figure out a fix for the twisty-style comments as
> well, but I'm also open to bagging it altogether since it doesn't work
> with the authenticators (unless we can call them using XHR).
>
> Matt
>
>>
>>
>> > I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
>> > have noticed an issue with the LineBreak Plugin.  As soon as it's
>> > added to an entry, the entry cannot be rendered and there's no  
>> way of
>> > getting it back - even though it's stored in the database and  
>> renders
>> > in the editor. Below is an example.
>> >
>> > http://virtuastravels.com/page/road?entry=a_federal_incident_8230
>> >
>> > Any ideas?
>>
>> That plugin works for me, so I bet  the problem is this: your roller-
>> custom.properties override file is still using the old org.roller
>> package names for the plugins. Change those to org.apach.roller and I
>> bet you'll be in business.
>>
>> - Dave
>>
>>


/roller/branches/roller_2.3

Posted by David M Johnson <Da...@Sun.COM>.
I've created a release branch for Roller 2.3

Mainline development can now continue in the main branch

Next, I'd like to create a development branch for Roller 3.0

- Dave


On May 10, 2006, at 12:29 PM, Matt Raible wrote:

> OK, I've created an issue for this and will try to work on it in the
> coming weeks.
>
> http://opensource.atlassian.com/projects/roller/browse/ROL-1131
>
> Matt
>
> On 5/10/06, Allen Gilliland <al...@sun.com> wrote:
>>
>>
>> David M Johnson wrote:
>> >
>> > On May 9, 2006, at 10:21 PM, Matt Raible wrote:
>> >>> Hmmm... I think we should consider that for 2.4. However, I don't
>> >>> like the idea of introducing another comment form macro. We  
>> already
>> >>> have two (regular and twisty-style) and we should really have  
>> just
>> >>> one. Can we change the existing comment form macro to make it CSS
>> >>> compliant/friendly instead?
>> >>
>> >> Yes.  We can certainly do this.  However, it might be somewhat  
>> tedious
>> >> to make sure it works across all the themes.
>> >
>> > It would definitely be an improvement. Many of the themes have no
>> > styling around the comment form and fields at all, so we'd  
>> probably only
>> > have to make corrections the couple nice themes that we have. And,
>> > maintaining multiple comment forms is going to be more tedious  
>> in the
>> > long run.
>>
>> I agree, we can't add another comments form macro so we need to  
>> fix up
>> the existing one.
>>
>>
>> >
>> >
>> >> Should I enter a bug for
>> >> it?  It'd be nice to figure out a fix for the twisty-style  
>> comments as
>> >> well, but I'm also open to bagging it altogether since it  
>> doesn't work
>> >> with the authenticators (unless we can call them using XHR).
>> >
>> > I removed twisty comments from the themes last year when we ran  
>> into
>> > problems with it, so I'm certainly not opposed to dropping it.
>>
>> whoot!  +1 on dropping extra macro junk!
>>
>> -- Allen
>>
>>
>> >
>> > - Dave
>> >
>>


Re: New comment macro(s) (was Re: Prev and Next Entries)

Posted by Matt Raible <mr...@gmail.com>.
OK, I've created an issue for this and will try to work on it in the
coming weeks.

http://opensource.atlassian.com/projects/roller/browse/ROL-1131

Matt

On 5/10/06, Allen Gilliland <al...@sun.com> wrote:
>
>
> David M Johnson wrote:
> >
> > On May 9, 2006, at 10:21 PM, Matt Raible wrote:
> >>> Hmmm... I think we should consider that for 2.4. However, I don't
> >>> like the idea of introducing another comment form macro. We already
> >>> have two (regular and twisty-style) and we should really have just
> >>> one. Can we change the existing comment form macro to make it CSS
> >>> compliant/friendly instead?
> >>
> >> Yes.  We can certainly do this.  However, it might be somewhat tedious
> >> to make sure it works across all the themes.
> >
> > It would definitely be an improvement. Many of the themes have no
> > styling around the comment form and fields at all, so we'd probably only
> > have to make corrections the couple nice themes that we have. And,
> > maintaining multiple comment forms is going to be more tedious in the
> > long run.
>
> I agree, we can't add another comments form macro so we need to fix up
> the existing one.
>
>
> >
> >
> >> Should I enter a bug for
> >> it?  It'd be nice to figure out a fix for the twisty-style comments as
> >> well, but I'm also open to bagging it altogether since it doesn't work
> >> with the authenticators (unless we can call them using XHR).
> >
> > I removed twisty comments from the themes last year when we ran into
> > problems with it, so I'm certainly not opposed to dropping it.
>
> whoot!  +1 on dropping extra macro junk!
>
> -- Allen
>
>
> >
> > - Dave
> >
>

Re: New comment macro(s) (was Re: Prev and Next Entries)

Posted by Allen Gilliland <al...@sun.com>.

David M Johnson wrote:
> 
> On May 9, 2006, at 10:21 PM, Matt Raible wrote:
>>> Hmmm... I think we should consider that for 2.4. However, I don't
>>> like the idea of introducing another comment form macro. We already
>>> have two (regular and twisty-style) and we should really have just
>>> one. Can we change the existing comment form macro to make it CSS
>>> compliant/friendly instead?
>>
>> Yes.  We can certainly do this.  However, it might be somewhat tedious
>> to make sure it works across all the themes.
> 
> It would definitely be an improvement. Many of the themes have no 
> styling around the comment form and fields at all, so we'd probably only 
> have to make corrections the couple nice themes that we have. And, 
> maintaining multiple comment forms is going to be more tedious in the 
> long run.

I agree, we can't add another comments form macro so we need to fix up 
the existing one.


> 
> 
>> Should I enter a bug for
>> it?  It'd be nice to figure out a fix for the twisty-style comments as
>> well, but I'm also open to bagging it altogether since it doesn't work
>> with the authenticators (unless we can call them using XHR).
> 
> I removed twisty comments from the themes last year when we ran into 
> problems with it, so I'm certainly not opposed to dropping it.

whoot!  +1 on dropping extra macro junk!

-- Allen


> 
> - Dave
> 

Re: New comment macro(s) (was Re: Prev and Next Entries)

Posted by David M Johnson <Da...@Sun.COM>.
On May 9, 2006, at 10:21 PM, Matt Raible wrote:
>> Hmmm... I think we should consider that for 2.4. However, I don't
>> like the idea of introducing another comment form macro. We already
>> have two (regular and twisty-style) and we should really have just
>> one. Can we change the existing comment form macro to make it CSS
>> compliant/friendly instead?
>
> Yes.  We can certainly do this.  However, it might be somewhat tedious
> to make sure it works across all the themes.

It would definitely be an improvement. Many of the themes have no  
styling around the comment form and fields at all, so we'd probably  
only have to make corrections the couple nice themes that we have.  
And, maintaining multiple comment forms is going to be more tedious  
in the long run.


> Should I enter a bug for
> it?  It'd be nice to figure out a fix for the twisty-style comments as
> well, but I'm also open to bagging it altogether since it doesn't work
> with the authenticators (unless we can call them using XHR).

I removed twisty comments from the themes last year when we ran into  
problems with it, so I'm certainly not opposed to dropping it.

- Dave


Re: New comment macro(s) (was Re: Prev and Next Entries)

Posted by Matt Raible <mr...@gmail.com>.
On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>
> On May 9, 2006, at 7:34 PM, Matt Raible wrote:
> > On 5/9/06, David M Johnson <Da...@sun.com> wrote:
> >> On May 9, 2006, at 6:01 PM, Matt Raible wrote:
> >> > My modifications to the *.vm templates fix JavaScript and CSS
> >> issues -
> >> > should those go in 2.3 or 2.4?
> >> I've already found 1 problem in RC2, so they could conceivably go in
> >> 2.3.
> >> How extensive and how risky are those *.vm changes?
> >
> > I've attached the patch so you can see.  The only major thing is a new
> > form for comments that more CSS-friendly. Other things include new
> > macros and fixing comments HTML so it renders with XHTML
> > compliance. I also fixed a bug in the JavaScript for Remember Me
> > (only happens
> > with IE).
>
> Hmmm... I think we should consider that for 2.4. However, I don't
> like the idea of introducing another comment form macro. We already
> have two (regular and twisty-style) and we should really have just
> one. Can we change the existing comment form macro to make it CSS
> compliant/friendly instead?

Yes.  We can certainly do this.  However, it might be somewhat tedious
to make sure it works across all the themes.  Should I enter a bug for
it?  It'd be nice to figure out a fix for the twisty-style comments as
well, but I'm also open to bagging it altogether since it doesn't work
with the authenticators (unless we can call them using XHR).

Matt

>
>
> > I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
> > have noticed an issue with the LineBreak Plugin.  As soon as it's
> > added to an entry, the entry cannot be rendered and there's no way of
> > getting it back - even though it's stored in the database and renders
> > in the editor. Below is an example.
> >
> > http://virtuastravels.com/page/road?entry=a_federal_incident_8230
> >
> > Any ideas?
>
> That plugin works for me, so I bet  the problem is this: your roller-
> custom.properties override file is still using the old org.roller
> package names for the plugins. Change those to org.apach.roller and I
> bet you'll be in business.
>
> - Dave
>
>

Re: New comment macro(s) (was Re: Prev and Next Entries)

Posted by Matt Raible <mr...@gmail.com>.
On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>
> On May 9, 2006, at 7:34 PM, Matt Raible wrote:
> > On 5/9/06, David M Johnson <Da...@sun.com> wrote:
> >> On May 9, 2006, at 6:01 PM, Matt Raible wrote:
> >> > My modifications to the *.vm templates fix JavaScript and CSS
> >> issues -
> >> > should those go in 2.3 or 2.4?
> >> I've already found 1 problem in RC2, so they could conceivably go in
> >> 2.3.
> >> How extensive and how risky are those *.vm changes?
> >
> > I've attached the patch so you can see.  The only major thing is a new
> > form for comments that more CSS-friendly. Other things include new
> > macros and fixing comments HTML so it renders with XHTML
> > compliance. I also fixed a bug in the JavaScript for Remember Me
> > (only happens
> > with IE).
>
> Hmmm... I think we should consider that for 2.4. However, I don't
> like the idea of introducing another comment form macro. We already
> have two (regular and twisty-style) and we should really have just
> one. Can we change the existing comment form macro to make it CSS
> compliant/friendly instead?
>
>
> > I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
> > have noticed an issue with the LineBreak Plugin.  As soon as it's
> > added to an entry, the entry cannot be rendered and there's no way of
> > getting it back - even though it's stored in the database and renders
> > in the editor. Below is an example.
> >
> > http://virtuastravels.com/page/road?entry=a_federal_incident_8230
> >
> > Any ideas?
>
> That plugin works for me, so I bet  the problem is this: your roller-
> custom.properties override file is still using the old org.roller
> package names for the plugins. Change those to org.apach.roller and I
> bet you'll be in business.

In my roller-custom.properties, all I have configured is:

uploads.dir=
search.index.dir=
editor.theme=

It might be that my custom weblog.vm is causing problems, but I don't
think so.  It's strange that the entry renders fine, but after
editing, it just says "null".

Matt

>
> - Dave
>
>

New comment macro(s) (was Re: Prev and Next Entries)

Posted by David M Johnson <Da...@Sun.COM>.
On May 9, 2006, at 7:34 PM, Matt Raible wrote:
> On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>> On May 9, 2006, at 6:01 PM, Matt Raible wrote:
>> > My modifications to the *.vm templates fix JavaScript and CSS  
>> issues -
>> > should those go in 2.3 or 2.4?
>> I've already found 1 problem in RC2, so they could conceivably go in
>> 2.3.
>> How extensive and how risky are those *.vm changes?
>
> I've attached the patch so you can see.  The only major thing is a new
> form for comments that more CSS-friendly. Other things include new
> macros and fixing comments HTML so it renders with XHTML  
> compliance. I also fixed a bug in the JavaScript for Remember Me  
> (only happens
> with IE).

Hmmm... I think we should consider that for 2.4. However, I don't  
like the idea of introducing another comment form macro. We already  
have two (regular and twisty-style) and we should really have just  
one. Can we change the existing comment form macro to make it CSS  
compliant/friendly instead?


> I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
> have noticed an issue with the LineBreak Plugin.  As soon as it's
> added to an entry, the entry cannot be rendered and there's no way of
> getting it back - even though it's stored in the database and renders
> in the editor. Below is an example.
>
> http://virtuastravels.com/page/road?entry=a_federal_incident_8230
>
> Any ideas?

That plugin works for me, so I bet  the problem is this: your roller- 
custom.properties override file is still using the old org.roller  
package names for the plugins. Change those to org.apach.roller and I  
bet you'll be in business.

- Dave


Re: Prev and Next Entries

Posted by Matt Raible <mr...@gmail.com>.
On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>
>
> On May 9, 2006, at 6:01 PM, Matt Raible wrote:
> > My modifications to the *.vm templates fix JavaScript and CSS issues -
> > should those go in 2.3 or 2.4?
>
> I've already found 1 problem in RC2, so they could conceivably go in
> 2.3.
>
> How extensive and how risky are those *.vm changes?

I've attached the patch so you can see.  The only major thing is a new
form for comments that more CSS-friendly. Other things include new
macros and fixing comments HTML so it renders with XHTML compliance. 
I also fixed a bug in the JavaScript for Remember Me (only happens
with IE).

I've successfully upgraded a site from 2.0 to 2.3 RC2 today, but I
have noticed an issue with the LineBreak Plugin.  As soon as it's
added to an entry, the entry cannot be rendered and there's no way of
getting it back - even though it's stored in the database and renders
in the editor. Below is an example.

http://virtuastravels.com/page/road?entry=a_federal_incident_8230

Any ideas?

Thanks,

Matt

>
> - Dave
>
>

Re: Prev and Next Entries

Posted by David M Johnson <Da...@Sun.COM>.

On May 9, 2006, at 6:01 PM, Matt Raible wrote:
> My modifications to the *.vm templates fix JavaScript and CSS issues -
> should those go in 2.3 or 2.4?

I've already found 1 problem in RC2, so they could conceivably go in  
2.3.

How extensive and how risky are those *.vm changes?

- Dave


Re: Prev and Next Entries

Posted by Matt Raible <mr...@gmail.com>.
My modifications to the *.vm templates fix JavaScript and CSS issues -
should those go in 2.3 or 2.4?

Here's what the theme looks like (but with the header graphic from
http://raibledesigns.com/page/rd?catname=%2FThe+Bus, sans logo):

http://virtuastravels.com/page/road

Matt

On 5/9/06, David M Johnson <Da...@sun.com> wrote:
>
> On May 9, 2006, at 5:24 PM, Allen Gilliland wrote:
> > Matt Raible wrote:
> >> On 5/8/06, Allen Gilliland <al...@sun.com> wrote:
> >>> =
> >>> >> Also, I'd like to contribute a version of my new theme to Roller.
> >>> >> Should I simple check it into "themes" or should it go into the
> >>> >> support project?
> >>> >
> >>> > If the new theme does not use LGPL, then I'd vote for Roller
> >>> "themes"
> >>>
> >>> Actually, I vote for support project.  Unless this is going to be
> >>> one of
> >>> the few themes that we ship with the default Roller package.
> >> I'm ready to check this theme in, along with some fixes for:
> >> website.vm
> >> navbar.vm
> >> comments.vm
> >> weblog.vm
> >
> > that stuff can go into trunk as long as Dave has the 2.3 branch/tag
> > prepared and it won't disrupt the 2.3 release stuff.
>
> I'll create a branch for 2.3 tonight so that dev can continue in trunk.
>
> I'll send out a note when I'm done.
>
> - Dave
>
>

Re: Prev and Next Entries

Posted by David M Johnson <Da...@Sun.COM>.
On May 9, 2006, at 5:24 PM, Allen Gilliland wrote:
> Matt Raible wrote:
>> On 5/8/06, Allen Gilliland <al...@sun.com> wrote:
>>> =
>>> >> Also, I'd like to contribute a version of my new theme to Roller.
>>> >> Should I simple check it into "themes" or should it go into the
>>> >> support project?
>>> >
>>> > If the new theme does not use LGPL, then I'd vote for Roller  
>>> "themes"
>>>
>>> Actually, I vote for support project.  Unless this is going to be  
>>> one of
>>> the few themes that we ship with the default Roller package.
>> I'm ready to check this theme in, along with some fixes for:
>> website.vm
>> navbar.vm
>> comments.vm
>> weblog.vm
>
> that stuff can go into trunk as long as Dave has the 2.3 branch/tag  
> prepared and it won't disrupt the 2.3 release stuff.

I'll create a branch for 2.3 tonight so that dev can continue in trunk.

I'll send out a note when I'm done.

- Dave


Re: Prev and Next Entries

Posted by Allen Gilliland <al...@sun.com>.

Matt Raible wrote:
> On 5/8/06, Allen Gilliland <al...@sun.com> wrote:
>>
>> >
>> >> Also, I'd like to contribute a version of my new theme to Roller.
>> >> Should I simple check it into "themes" or should it go into the
>> >> support project?
>> >
>> > If the new theme does not use LGPL, then I'd vote for Roller "themes"
>>
>> Actually, I vote for support project.  Unless this is going to be one of
>> the few themes that we ship with the default Roller package.
> 
> I'm ready to check this theme in, along with some fixes for:
> 
> website.vm
> navbar.vm
> comments.vm
> weblog.vm

that stuff can go into trunk as long as Dave has the 2.3 branch/tag 
prepared and it won't disrupt the 2.3 release stuff.

> 
> Where should I check the theme in at?  I'd like to see it somehow
> distributed with Roller, but understand if it should go into the
> support project.  The good news is this theme is based on the CSS
> Framework (http://www.contentwithstyle.co.uk/Articles/17/), so it
> should be able to change the layout *and* look n' feel without
> modifying any *.vm templates - just CSS.

maybe you can put it in the sandbox or on the support project cvs at 
first so that we can take a look at it and maybe vote on whether it 
should go in as one of the default themes.  since the long term goal is 
to only support 2-3 themes then i think it makes sense that have a 
fairly strict vote before any new themes go into the trunk.

-- Allen


> 
> Thanks,
> 
> Matt
> 
> P.S. I'd also like to upgrade Acegi to 1.0 RC2. For some reason, I'm
> running this on my site, and it's not in Roller (RC1 is in Roller). Is
> 2.3 RC2 in a branch or on HEAD?
> 
>>
>> -- Allen
>>
>>
>> >
>> > - Dave
>> >
>>

Re: Prev and Next Entries

Posted by Matt Raible <mr...@gmail.com>.
On 5/8/06, Allen Gilliland <al...@sun.com> wrote:
>
> >
> >> Also, I'd like to contribute a version of my new theme to Roller.
> >> Should I simple check it into "themes" or should it go into the
> >> support project?
> >
> > If the new theme does not use LGPL, then I'd vote for Roller "themes"
>
> Actually, I vote for support project.  Unless this is going to be one of
> the few themes that we ship with the default Roller package.

I'm ready to check this theme in, along with some fixes for:

website.vm
navbar.vm
comments.vm
weblog.vm

Where should I check the theme in at?  I'd like to see it somehow
distributed with Roller, but understand if it should go into the
support project.  The good news is this theme is based on the CSS
Framework (http://www.contentwithstyle.co.uk/Articles/17/), so it
should be able to change the layout *and* look n' feel without
modifying any *.vm templates - just CSS.

Thanks,

Matt

P.S. I'd also like to upgrade Acegi to 1.0 RC2. For some reason, I'm
running this on my site, and it's not in Roller (RC1 is in Roller). Is
2.3 RC2 in a branch or on HEAD?

>
> -- Allen
>
>
> >
> > - Dave
> >
>

Re: Prev and Next Entries

Posted by Allen Gilliland <al...@sun.com>.
> 
>> Also, I'd like to contribute a version of my new theme to Roller. 
>> Should I simple check it into "themes" or should it go into the
>> support project?
> 
> If the new theme does not use LGPL, then I'd vote for Roller "themes"

Actually, I vote for support project.  Unless this is going to be one of 
the few themes that we ship with the default Roller package.

-- Allen


> 
> - Dave
> 

Re: Prev and Next Entries

Posted by Dave Johnson <da...@rollerweblogger.org>.
On May 8, 2006, at 4:22 PM, Matt Raible wrote:
> The current "prev and next" feature in 2.2 works, but it only ever
> allows me to go back one entry at a time.  Ideally, I'd like to see
> something like the following:
>
> 1. If the user is viewing more than one day (for example, the default
> view with 15 entries), the "prev" link will take then to the previous
> X number of entries (ideally X is the same number as is currently
> shown).

Currently, if you are looking the default view the previous link will  
take you to the previous day view. I don't think this is ideal, but  
we haven't yet introduced an offset for paging through blog entries  
within a blog.


> 2. If the user is viewing a particular day, "prev" takes them to the
> previous day.  This one might be tricky since YYYYMMDD shows a
> particular day at the top and previous days below it.  This one should
> probably operate like #1.

That's how it works now (on my blog and blogs.sun.com blogs).


> 3. When viewing a single entry, clicking "prev" navigates one entry at
> a time. This might not even make sense as clicking "prev" and seeing
> the previous entry at the top of a long list of entries is desireable.

I'd prefer to keep single entry view, with next and prev that go to  
single entry pages. That's how other systems work and it's cache  
friendly because single entry pages are small.


> Also, I'd like to contribute a version of my new theme to Roller.  
> Should I simple check it into "themes" or should it go into the
> support project?

If the new theme does not use LGPL, then I'd vote for Roller "themes"

- Dave