List Info

Thread: PROPOSAL: Template Editor Enhancements




PROPOSAL: Template Editor Enhancements
user name
2007-03-19 09:00:14
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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements

Please review, I'd like to commit this work this week.

- Dave

Re: PROPOSAL: Template Editor Enhancements
country flaguser name
United States
2007-03-19 16:01:11
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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements 
> 
> 
> Please review, I'd like to commit this work this week.
> 
> - Dave

Re: PROPOSAL: Template Editor Enhancements
user name
2007-03-19 16:12:02
On 3/19/07, Allen Gilliland <allen.gillilandsun.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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements
> >
> >
> > Please review, I'd like to commit this work this
week.
> >
> > - Dave
>

Re: PROPOSAL: Template Editor Enhancements
country flaguser name
United States
2007-03-19 16:12:06
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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements
>>
>>
>> Please review, I'd like to commit this work this
week.
>>
>> - Dave
> 

Re: PROPOSAL: Template Editor Enhancements
user name
2007-03-19 16:21:16
On 3/19/07, Elias Torres <eliastorrez.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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements
> >>
> >>
> >> Please review, I'd like to commit this work
this week.
> >>
> >> - Dave
> >
>

Re: PROPOSAL: Template Editor Enhancements
country flaguser name
United States
2007-03-19 16:24:47
+1 go for it.

-Elias

Dave wrote:
> On 3/19/07, Elias Torres <eliastorrez.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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements
>>
>> >>
>> >>
>> >> Please review, I'd like to commit this
work this week.
>> >>
>> >> - Dave
>> >
>>
> 

Re: PROPOSAL: Template Editor Enhancements
country flaguser name
United States
2007-03-19 16:51:35
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 <eliastorrez.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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements
>>
>> >>
>> >>
>> >> Please review, I'd like to commit this
work this week.
>> >>
>> >> - Dave
>> >
>>
> 

Re: PROPOSAL: Template Editor Enhancements
user name
2007-03-19 21:29:27
On 3/19/07, Allen Gilliland <allen.gillilandsun.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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements
> >
> >
> > Please review, I'd like to commit this work this
week.
> >
> > - Dave
>

Re: PROPOSAL: Template Editor Enhancements
country flaguser name
United States
2007-03-21 11:59:37

Dave wrote:
> On 3/19/07, Allen Gilliland <allen.gillilandsun.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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements 
>>
>> >
>> >
>> > Please review, I'd like to commit this work
this week.
>> >
>> > - Dave
>>

Re: PROPOSAL: Template Editor Enhancements
country flaguser name
United States
2007-03-23 03:44:51
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 <allen.gillilandsun.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/con
fluence/display/ROLLER/Proposal_TemplateEditorEnhancements 
>>
>> >
>> >
>> > Please review, I'd like to commit this work
this week.
>> >
>> > - Dave
>>

[1-10] [11]

about | contact  Other archives ( Real Estate discussion Medical topics )