You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave <sn...@gmail.com> on 2007/03/19 15:00:14 UTC
PROPOSAL: Template Editor Enhancements
This is a proposal to make some minor usability and functionality
improvements to the UI of the Template Editor pages. The functionality
improvements allow a user to set the content-type and language for a
page, with together make it possible to take advantage of the Roller
rendering system's pluggable renderers.
Screen-shots included in proposal:
http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
Please review, I'd like to commit this work this week.
- Dave
Re: PROPOSAL: Template Editor Enhancements
Posted by Dave <sn...@gmail.com>.
On 3/19/07, Allen Gilliland <al...@sun.com> wrote:
> I agree with most of these changes, but here's a few things I don't
> really like ...
Good feedback. I agree with all of these changes.
Anybody else have feedback on this?
- Dave
>
> 1. On the templates list page I don't think we need the column for the
> content-type. The overwhelming majority of users don't care about
> manually managing the content type for their templates so I think we
> want to keep that completely hidden and only available in that advanced
> settings section.
>
> 2. On the templates list page I don't like having 2 columns which are
> links. To me that is confusing and bad usability, so I think that only
> the template name should be a link. In fact, I don't think we need to
> have the "link" column in the templates list page at all. I don't
> really think it adds much value and we are best off just making things
> as simple as possible.
>
> So with #1 and #2 applied I think that the templates list page should
> just include Name, Description, and the icon for locked/delete. This is
> a good thing too because it will leave more room for better
> descriptions, which is something I think we should do for our
> standardized templates like the Weblog template.
>
> 3. I would put the content-type and template language controls as the
> first 2 elements under the advanced settings page.
>
> 4. I think the content-type control should work differently than you
> described. I think the only 2 options should be "automatic" and
> "manual". So for automatic content-type it would work exactly how it
> does now where we ask the appserver for the content type based on the
> link value and text/html is the default. For manual we just provide a
> textfield for the user to specify whatever they want. Default would be
> for automatic content-type detection. And with the automatic
> content-type detection we would actually do that at the time the form is
> submitted rather than at rendering time like we do now.
>
> -- Allen
>
>
> Dave wrote:
> > This is a proposal to make some minor usability and functionality
> > improvements to the UI of the Template Editor pages. The functionality
> > improvements allow a user to set the content-type and language for a
> > page, with together make it possible to take advantage of the Roller
> > rendering system's pluggable renderers.
> >
> > Screen-shots included in proposal:
> > http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
> >
> >
> > Please review, I'd like to commit this work this week.
> >
> > - Dave
>
Re: PROPOSAL: Template Editor Enhancements
Posted by Allen Gilliland <al...@sun.com>.
Dave wrote:
> On 3/19/07, Allen Gilliland <al...@sun.com> wrote:
>> 4. I think the content-type control should work differently than you
>> described. I think the only 2 options should be "automatic" and
>> "manual". So for automatic content-type it would work exactly how it
>> does now where we ask the appserver for the content type based on the
>> link value and text/html is the default. For manual we just provide a
>> textfield for the user to specify whatever they want. Default would be
>> for automatic content-type detection. And with the automatic
>> content-type detection we would actually do that at the time the form is
>> submitted rather than at rendering time like we do now.
>
> OK. I committed this work and got your change #4 in, but...
>
> We need some way to determine that a WeblogTemplate uses a "manual"
> vs. an "automatic" content-type. I mean, if we fill in the
> content-ype field at form-post time how will we know that it's an
> automatically detected one or a manually entered one?
>
> If we really want the content-type to be determined at form post time
> rather than content rendering time, then we'll need a new field
> WeblogTemplate.autoContentType. I didn't go that route. Instead, a
> null content type indicates that automatic content type detection
> should be done. Or maybe you've got another idea.
Good point. I think your solution sounds good.
>
> Think this warrants a new autoContentType database field?
naw, what you have now works.
-- Allen
>
> - Dave
>
>
>
>> Dave wrote:
>> > This is a proposal to make some minor usability and functionality
>> > improvements to the UI of the Template Editor pages. The functionality
>> > improvements allow a user to set the content-type and language for a
>> > page, with together make it possible to take advantage of the Roller
>> > rendering system's pluggable renderers.
>> >
>> > Screen-shots included in proposal:
>> >
>> http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
>>
>> >
>> >
>> > Please review, I'd like to commit this work this week.
>> >
>> > - Dave
>>
Re: PROPOSAL: Template Editor Enhancements
Posted by Allen Gilliland <al...@sun.com>.
Dave wrote:
> On 3/23/07, Allen Gilliland <al...@sun.com> wrote:
>> Now that I've looked at this a bit I have a couple more things that I
>> would like to suggest ...
>>
>> 1. If the template is required (or tied to a specific action in the
>> upcoming code) then we don't show the Name, Link, and Description
>> elements as form fields. Instead we just provide targeted help text to
>> explain exactly how the specific template relates to the weblog design.
>
> I think name, link and description are helpful bits of information and
> I don't see any reason to stop displaying them. They don't have to be
> greyed out form fields, they could just be text.
Right, they would all still be there on custom templates, but for our
special templates they don't really make much sense. Consider that the
Weblog template shows "Weblog", <empty>, "Weblog" for it's name, link,
description, which is totally useless to users. Instead what I am
proposing is that we would just remove all of those form fields and
instead provide a very targeted message saying something like ... "This
is your main weblog template which is used to display your weblog
homepage and other views of your weblog entries. etc, etc, etc ..."
>
>
>> 2. I am starting to think that we don't really need the 'description'
>> property of a template. How many people actually want to put in a
>> description for their template? I think that the template name serves
>> as enough of a description and the less form fields users have to deal
>> with the better.
>
> -1. I use it and find it quite helpful.
>
> If you've got a large number of templates, then having a description
> field is quite helpful.
fair enough. just a thought.
>
>
>> 3. I don't think the content type controls need to be available for
>> templates that are required. It wouldn't make much sense to change the
>> content type for the Weblog template, for example.
>
> -1 on this too. Some bloggers want XHTML.
>
> Bloggers and theme designers should be able to pick the content type
> of their blog. Some folks are going to want HTLML 4 (text/html), some
> are going to require XHTML (application/xhtml+xml) and some might want
> XML + XSLT -- we should force everybody to use text/html.
hadn't thought about that, but it makes sense.
-- Allen
>
> - Dave
Re: PROPOSAL: Template Editor Enhancements
Posted by Dave <sn...@gmail.com>.
On 3/23/07, Allen Gilliland <al...@sun.com> wrote:
> Now that I've looked at this a bit I have a couple more things that I
> would like to suggest ...
>
> 1. If the template is required (or tied to a specific action in the
> upcoming code) then we don't show the Name, Link, and Description
> elements as form fields. Instead we just provide targeted help text to
> explain exactly how the specific template relates to the weblog design.
I think name, link and description are helpful bits of information and
I don't see any reason to stop displaying them. They don't have to be
greyed out form fields, they could just be text.
> 2. I am starting to think that we don't really need the 'description'
> property of a template. How many people actually want to put in a
> description for their template? I think that the template name serves
> as enough of a description and the less form fields users have to deal
> with the better.
-1. I use it and find it quite helpful.
If you've got a large number of templates, then having a description
field is quite helpful.
> 3. I don't think the content type controls need to be available for
> templates that are required. It wouldn't make much sense to change the
> content type for the Weblog template, for example.
-1 on this too. Some bloggers want XHTML.
Bloggers and theme designers should be able to pick the content type
of their blog. Some folks are going to want HTLML 4 (text/html), some
are going to require XHTML (application/xhtml+xml) and some might want
XML + XSLT -- we should force everybody to use text/html.
- Dave
Re: PROPOSAL: Template Editor Enhancements
Posted by Allen Gilliland <al...@sun.com>.
Now that I've looked at this a bit I have a couple more things that I
would like to suggest ...
1. If the template is required (or tied to a specific action in the
upcoming code) then we don't show the Name, Link, and Description
elements as form fields. Instead we just provide targeted help text to
explain exactly how the specific template relates to the weblog design.
2. I am starting to think that we don't really need the 'description'
property of a template. How many people actually want to put in a
description for their template? I think that the template name serves
as enough of a description and the less form fields users have to deal
with the better.
3. I don't think the content type controls need to be available for
templates that are required. It wouldn't make much sense to change the
content type for the Weblog template, for example.
Just some small tweaks really. I think the way the templates section
works now is much nicer than it was before, so we are definitely moving
in the right direction.
-- Allen
Dave wrote:
> On 3/19/07, Allen Gilliland <al...@sun.com> wrote:
>> 4. I think the content-type control should work differently than you
>> described. I think the only 2 options should be "automatic" and
>> "manual". So for automatic content-type it would work exactly how it
>> does now where we ask the appserver for the content type based on the
>> link value and text/html is the default. For manual we just provide a
>> textfield for the user to specify whatever they want. Default would be
>> for automatic content-type detection. And with the automatic
>> content-type detection we would actually do that at the time the form is
>> submitted rather than at rendering time like we do now.
>
> OK. I committed this work and got your change #4 in, but...
>
> We need some way to determine that a WeblogTemplate uses a "manual"
> vs. an "automatic" content-type. I mean, if we fill in the
> content-ype field at form-post time how will we know that it's an
> automatically detected one or a manually entered one?
>
> If we really want the content-type to be determined at form post time
> rather than content rendering time, then we'll need a new field
> WeblogTemplate.autoContentType. I didn't go that route. Instead, a
> null content type indicates that automatic content type detection
> should be done. Or maybe you've got another idea.
>
> Think this warrants a new autoContentType database field?
>
> - Dave
>
>
>
>> Dave wrote:
>> > This is a proposal to make some minor usability and functionality
>> > improvements to the UI of the Template Editor pages. The functionality
>> > improvements allow a user to set the content-type and language for a
>> > page, with together make it possible to take advantage of the Roller
>> > rendering system's pluggable renderers.
>> >
>> > Screen-shots included in proposal:
>> >
>> http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
>>
>> >
>> >
>> > Please review, I'd like to commit this work this week.
>> >
>> > - Dave
>>
Re: PROPOSAL: Template Editor Enhancements
Posted by Dave <sn...@gmail.com>.
On 3/19/07, Allen Gilliland <al...@sun.com> wrote:
> 4. I think the content-type control should work differently than you
> described. I think the only 2 options should be "automatic" and
> "manual". So for automatic content-type it would work exactly how it
> does now where we ask the appserver for the content type based on the
> link value and text/html is the default. For manual we just provide a
> textfield for the user to specify whatever they want. Default would be
> for automatic content-type detection. And with the automatic
> content-type detection we would actually do that at the time the form is
> submitted rather than at rendering time like we do now.
OK. I committed this work and got your change #4 in, but...
We need some way to determine that a WeblogTemplate uses a "manual"
vs. an "automatic" content-type. I mean, if we fill in the
content-ype field at form-post time how will we know that it's an
automatically detected one or a manually entered one?
If we really want the content-type to be determined at form post time
rather than content rendering time, then we'll need a new field
WeblogTemplate.autoContentType. I didn't go that route. Instead, a
null content type indicates that automatic content type detection
should be done. Or maybe you've got another idea.
Think this warrants a new autoContentType database field?
- Dave
> Dave wrote:
> > This is a proposal to make some minor usability and functionality
> > improvements to the UI of the Template Editor pages. The functionality
> > improvements allow a user to set the content-type and language for a
> > page, with together make it possible to take advantage of the Roller
> > rendering system's pluggable renderers.
> >
> > Screen-shots included in proposal:
> > http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
> >
> >
> > Please review, I'd like to commit this work this week.
> >
> > - Dave
>
Re: PROPOSAL: Template Editor Enhancements
Posted by Elias Torres <el...@torrez.us>.
+1 go for it.
-Elias
Dave wrote:
> On 3/19/07, Elias Torres <el...@torrez.us> wrote:
>> Does this work depend on groovy, ruby, etc?
>
> No.
>
> Apart from the UI tweaks, all I'm doing is adding a way for users to
> specify for each Template:
> 1) the template language used by the page and
> 2) the content-type generated by a template.
>
> Roller already supports plugin renderrers and the renderer that is
> chosen depends on the renderrers that are configured and the
> template-language of the page being. This change simply makes it
> possible to use plugin renderrers without editing the database via SQL
> to set each page's language name.
>
> I have developed some plugin renderrers for Groovy and JavaScript and
> though they are currently in the sandbox, the Roller Support project
> might be a better home for them.
>
> - Dave
>
>
>
>> -Elias
>>
>> Allen Gilliland wrote:
>> > I agree with most of these changes, but here's a few things I don't
>> > really like ...
>> >
>> > 1. On the templates list page I don't think we need the column for the
>> > content-type. The overwhelming majority of users don't care about
>> > manually managing the content type for their templates so I think we
>> > want to keep that completely hidden and only available in that advanced
>> > settings section.
>> >
>> > 2. On the templates list page I don't like having 2 columns which are
>> > links. To me that is confusing and bad usability, so I think that only
>> > the template name should be a link. In fact, I don't think we need to
>> > have the "link" column in the templates list page at all. I don't
>> > really think it adds much value and we are best off just making things
>> > as simple as possible.
>> >
>> > So with #1 and #2 applied I think that the templates list page should
>> > just include Name, Description, and the icon for locked/delete.
>> This is
>> > a good thing too because it will leave more room for better
>> > descriptions, which is something I think we should do for our
>> > standardized templates like the Weblog template.
>> >
>> > 3. I would put the content-type and template language controls as the
>> > first 2 elements under the advanced settings page.
>> >
>> > 4. I think the content-type control should work differently than you
>> > described. I think the only 2 options should be "automatic" and
>> > "manual". So for automatic content-type it would work exactly how it
>> > does now where we ask the appserver for the content type based on the
>> > link value and text/html is the default. For manual we just provide a
>> > textfield for the user to specify whatever they want. Default would be
>> > for automatic content-type detection. And with the automatic
>> > content-type detection we would actually do that at the time the
>> form is
>> > submitted rather than at rendering time like we do now.
>> >
>> > -- Allen
>> >
>> >
>> > Dave wrote:
>> >> This is a proposal to make some minor usability and functionality
>> >> improvements to the UI of the Template Editor pages. The functionality
>> >> improvements allow a user to set the content-type and language for a
>> >> page, with together make it possible to take advantage of the Roller
>> >> rendering system's pluggable renderers.
>> >>
>> >> Screen-shots included in proposal:
>> >>
>> http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
>>
>> >>
>> >>
>> >> Please review, I'd like to commit this work this week.
>> >>
>> >> - Dave
>> >
>>
>
Re: PROPOSAL: Template Editor Enhancements
Posted by James M Snell <ja...@gmail.com>.
One additional point that I would definitely like to see covered are
template pages that require user authentication.
- James
Dave wrote:
> On 3/19/07, Elias Torres <el...@torrez.us> wrote:
>> Does this work depend on groovy, ruby, etc?
>
> No.
>
> Apart from the UI tweaks, all I'm doing is adding a way for users to
> specify for each Template:
> 1) the template language used by the page and
> 2) the content-type generated by a template.
>
> Roller already supports plugin renderrers and the renderer that is
> chosen depends on the renderrers that are configured and the
> template-language of the page being. This change simply makes it
> possible to use plugin renderrers without editing the database via SQL
> to set each page's language name.
>
> I have developed some plugin renderrers for Groovy and JavaScript and
> though they are currently in the sandbox, the Roller Support project
> might be a better home for them.
>
> - Dave
>
>
>
>> -Elias
>>
>> Allen Gilliland wrote:
>> > I agree with most of these changes, but here's a few things I don't
>> > really like ...
>> >
>> > 1. On the templates list page I don't think we need the column for the
>> > content-type. The overwhelming majority of users don't care about
>> > manually managing the content type for their templates so I think we
>> > want to keep that completely hidden and only available in that advanced
>> > settings section.
>> >
>> > 2. On the templates list page I don't like having 2 columns which are
>> > links. To me that is confusing and bad usability, so I think that only
>> > the template name should be a link. In fact, I don't think we need to
>> > have the "link" column in the templates list page at all. I don't
>> > really think it adds much value and we are best off just making things
>> > as simple as possible.
>> >
>> > So with #1 and #2 applied I think that the templates list page should
>> > just include Name, Description, and the icon for locked/delete.
>> This is
>> > a good thing too because it will leave more room for better
>> > descriptions, which is something I think we should do for our
>> > standardized templates like the Weblog template.
>> >
>> > 3. I would put the content-type and template language controls as the
>> > first 2 elements under the advanced settings page.
>> >
>> > 4. I think the content-type control should work differently than you
>> > described. I think the only 2 options should be "automatic" and
>> > "manual". So for automatic content-type it would work exactly how it
>> > does now where we ask the appserver for the content type based on the
>> > link value and text/html is the default. For manual we just provide a
>> > textfield for the user to specify whatever they want. Default would be
>> > for automatic content-type detection. And with the automatic
>> > content-type detection we would actually do that at the time the
>> form is
>> > submitted rather than at rendering time like we do now.
>> >
>> > -- Allen
>> >
>> >
>> > Dave wrote:
>> >> This is a proposal to make some minor usability and functionality
>> >> improvements to the UI of the Template Editor pages. The functionality
>> >> improvements allow a user to set the content-type and language for a
>> >> page, with together make it possible to take advantage of the Roller
>> >> rendering system's pluggable renderers.
>> >>
>> >> Screen-shots included in proposal:
>> >>
>> http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
>>
>> >>
>> >>
>> >> Please review, I'd like to commit this work this week.
>> >>
>> >> - Dave
>> >
>>
>
Re: PROPOSAL: Template Editor Enhancements
Posted by Dave <sn...@gmail.com>.
On 3/19/07, Elias Torres <el...@torrez.us> wrote:
> Does this work depend on groovy, ruby, etc?
No.
Apart from the UI tweaks, all I'm doing is adding a way for users to
specify for each Template:
1) the template language used by the page and
2) the content-type generated by a template.
Roller already supports plugin renderrers and the renderer that is
chosen depends on the renderrers that are configured and the
template-language of the page being. This change simply makes it
possible to use plugin renderrers without editing the database via SQL
to set each page's language name.
I have developed some plugin renderrers for Groovy and JavaScript and
though they are currently in the sandbox, the Roller Support project
might be a better home for them.
- Dave
> -Elias
>
> Allen Gilliland wrote:
> > I agree with most of these changes, but here's a few things I don't
> > really like ...
> >
> > 1. On the templates list page I don't think we need the column for the
> > content-type. The overwhelming majority of users don't care about
> > manually managing the content type for their templates so I think we
> > want to keep that completely hidden and only available in that advanced
> > settings section.
> >
> > 2. On the templates list page I don't like having 2 columns which are
> > links. To me that is confusing and bad usability, so I think that only
> > the template name should be a link. In fact, I don't think we need to
> > have the "link" column in the templates list page at all. I don't
> > really think it adds much value and we are best off just making things
> > as simple as possible.
> >
> > So with #1 and #2 applied I think that the templates list page should
> > just include Name, Description, and the icon for locked/delete. This is
> > a good thing too because it will leave more room for better
> > descriptions, which is something I think we should do for our
> > standardized templates like the Weblog template.
> >
> > 3. I would put the content-type and template language controls as the
> > first 2 elements under the advanced settings page.
> >
> > 4. I think the content-type control should work differently than you
> > described. I think the only 2 options should be "automatic" and
> > "manual". So for automatic content-type it would work exactly how it
> > does now where we ask the appserver for the content type based on the
> > link value and text/html is the default. For manual we just provide a
> > textfield for the user to specify whatever they want. Default would be
> > for automatic content-type detection. And with the automatic
> > content-type detection we would actually do that at the time the form is
> > submitted rather than at rendering time like we do now.
> >
> > -- Allen
> >
> >
> > Dave wrote:
> >> This is a proposal to make some minor usability and functionality
> >> improvements to the UI of the Template Editor pages. The functionality
> >> improvements allow a user to set the content-type and language for a
> >> page, with together make it possible to take advantage of the Roller
> >> rendering system's pluggable renderers.
> >>
> >> Screen-shots included in proposal:
> >> http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
> >>
> >>
> >> Please review, I'd like to commit this work this week.
> >>
> >> - Dave
> >
>
Re: PROPOSAL: Template Editor Enhancements
Posted by Elias Torres <el...@torrez.us>.
Does this work depend on groovy, ruby, etc?
-Elias
Allen Gilliland wrote:
> I agree with most of these changes, but here's a few things I don't
> really like ...
>
> 1. On the templates list page I don't think we need the column for the
> content-type. The overwhelming majority of users don't care about
> manually managing the content type for their templates so I think we
> want to keep that completely hidden and only available in that advanced
> settings section.
>
> 2. On the templates list page I don't like having 2 columns which are
> links. To me that is confusing and bad usability, so I think that only
> the template name should be a link. In fact, I don't think we need to
> have the "link" column in the templates list page at all. I don't
> really think it adds much value and we are best off just making things
> as simple as possible.
>
> So with #1 and #2 applied I think that the templates list page should
> just include Name, Description, and the icon for locked/delete. This is
> a good thing too because it will leave more room for better
> descriptions, which is something I think we should do for our
> standardized templates like the Weblog template.
>
> 3. I would put the content-type and template language controls as the
> first 2 elements under the advanced settings page.
>
> 4. I think the content-type control should work differently than you
> described. I think the only 2 options should be "automatic" and
> "manual". So for automatic content-type it would work exactly how it
> does now where we ask the appserver for the content type based on the
> link value and text/html is the default. For manual we just provide a
> textfield for the user to specify whatever they want. Default would be
> for automatic content-type detection. And with the automatic
> content-type detection we would actually do that at the time the form is
> submitted rather than at rendering time like we do now.
>
> -- Allen
>
>
> Dave wrote:
>> This is a proposal to make some minor usability and functionality
>> improvements to the UI of the Template Editor pages. The functionality
>> improvements allow a user to set the content-type and language for a
>> page, with together make it possible to take advantage of the Roller
>> rendering system's pluggable renderers.
>>
>> Screen-shots included in proposal:
>> http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
>>
>>
>> Please review, I'd like to commit this work this week.
>>
>> - Dave
>
Re: PROPOSAL: Template Editor Enhancements
Posted by Allen Gilliland <al...@sun.com>.
I agree with most of these changes, but here's a few things I don't
really like ...
1. On the templates list page I don't think we need the column for the
content-type. The overwhelming majority of users don't care about
manually managing the content type for their templates so I think we
want to keep that completely hidden and only available in that advanced
settings section.
2. On the templates list page I don't like having 2 columns which are
links. To me that is confusing and bad usability, so I think that only
the template name should be a link. In fact, I don't think we need to
have the "link" column in the templates list page at all. I don't
really think it adds much value and we are best off just making things
as simple as possible.
So with #1 and #2 applied I think that the templates list page should
just include Name, Description, and the icon for locked/delete. This is
a good thing too because it will leave more room for better
descriptions, which is something I think we should do for our
standardized templates like the Weblog template.
3. I would put the content-type and template language controls as the
first 2 elements under the advanced settings page.
4. I think the content-type control should work differently than you
described. I think the only 2 options should be "automatic" and
"manual". So for automatic content-type it would work exactly how it
does now where we ask the appserver for the content type based on the
link value and text/html is the default. For manual we just provide a
textfield for the user to specify whatever they want. Default would be
for automatic content-type detection. And with the automatic
content-type detection we would actually do that at the time the form is
submitted rather than at rendering time like we do now.
-- Allen
Dave wrote:
> This is a proposal to make some minor usability and functionality
> improvements to the UI of the Template Editor pages. The functionality
> improvements allow a user to set the content-type and language for a
> page, with together make it possible to take advantage of the Roller
> rendering system's pluggable renderers.
>
> Screen-shots included in proposal:
> http://cwiki.apache.org/confluence/display/ROLLER/Proposal_TemplateEditorEnhancements
>
>
> Please review, I'd like to commit this work this week.
>
> - Dave