You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Sean Gilligan <se...@catalla.com> on 2005/12/15 02:50:52 UTC
Patch submitted for RSD, RSS, etc.
I went ahead and attached an "svn diff" (I'm not sure that's the right
way to submit a patch, let me know if it isn't) to ROL-930.
This patch fixes ROL-899, ROL-930 and also uses
#showContentType("text/html; charset=utf-8") in place of a direct <meta>
tag for consistency between templates.
Further, some files had CRLF instead of LF, so I changed/fixed that, too.
If we later decide to write an RSDServlet, we can change the
#showRSDLink() macro and the theme templates won't have to change.
Regards,
Sean
RSDServlet and SpringMVC (was Re: Patch submitted for RSD, RSS, etc.)
Posted by Sean Gilligan <se...@msgilligan.com>.
Hi,
I'm creating a new thread for this because it is a bit of a tangent...
I'd like to get RSD added in the easiest agreed-upon way and am willing
to help as needed. That said, I've got "Spring Fever" these days, so I
can't help but propose the following...
Allen Gilliland wrote:
>
> I think the RSDServlet is a good place to start to break this habit by
> being very lightweight and only hitting the db for things it really
> needs, and also by creating it's own velocity context populated with
> only the items it needs.
>
I think your point about making things modular and lightweight is a
good one (but I really don't know the current code.)
After using SpringMVC, adding more servlets into web.xml isn't my first
choice. It would be nice to have some kind of framework where you could
move functions around to different URL configurations more easily than
using web.xml. I know this can be done with Struts, but don't know the
details.
I think SpringMVC controllers with Velocity Views could be a good way to
do this, but don't know if people would want to introduce SpringMVC as
yet another MVC framework inside Roller. I do have experience with
using SpringMVC to put new functionality into webapps built with other
frameworks and it is fairly lightweight.
SpringMVC could also be a good way to create prettier permalinks and
perhaps to better support having a blog on a virtual host. (by creating
a HandlerMapping...)
It would be nice if blogs could be accessed like this:
virtualhost.com/page/2005/12/12/armchair-developer.html
or
roller.mainhost.com/weblog-handle/page/2005/12/12/armchair-developer.html
Rather than the current mechanism where it is page/weblog-handle.
Regards,
Sean
Re: Patch submitted for RSD, RSS, etc.
Posted by Sean Gilligan <se...@msgilligan.com>.
The patch that I previously submitted contained the following:
1) Added #showRSDLink() macro to WEB-INF/classes/website.vm
2) Added new file WEB-INF/classes/flavors/rsd.vm
3) Modifications to theme templates:
M themes/brushedmetal/Weblog.vm
M themes/basic/_decorator.vm
M themes/clean/Weblog.vm
M themes/robot/Weblog.vm
M themes/grey2/Weblog.vm
M themes/x2/Weblog.vm
M themes/currency/Weblog.vm
M themes/berkley/Weblog.vm
M themes/pacifica/Weblog.vm
M themes/moonshine/Weblog.vm
M themes/cheb/Weblog.vm
M themes/werner/Weblog.vm
M themes/sunsets/Weblog.vm
M themes/rolling/_header.vm
M themes/movablemanila/Weblog.vm
M themes/currency-i18n/Weblog.vm
M themes/sotto/Weblog.vm
I can resubmit the patch with the #showRSDLink() macro updated for the
new RSD URL. Should I remove rsd.vm from the patch? Also I generated
the patch with "svn diff" on the 2.0 branch, is that the right/best way
to do it?
-- Sean
Allen Gilliland wrote:
>> Should I resubmit my patch with website.vm referencing the new RSD url?
>> Should I also move rsd.vm to another location? Should I add this
>> servlet to the patch? What about web.xml? Is it generated by xdoclet?
>
> yes, we will need to use the new RSD url. i will handle the rest as far as adding the RSDServlet and rsd.vm.
>
> -- Allen
>
>
Re: Patch submitted for RSD, RSS, etc.
Posted by Allen Gilliland <Al...@Sun.COM>.
On Fri, 2005-12-16 at 12:46, Sean Gilligan wrote:
> Thanks, Allen. Looks good! My only suggestion for a possible change is
> that perhaps the rsd.vm file shouldn't live in the "flavors" directory,
> since it is no longer being served by the FlavorServlet?
true, however i don't think that's a big deal. we actually had things that way for the foaf feeds already.
>
> Should I resubmit my patch with website.vm referencing the new RSD url?
> Should I also move rsd.vm to another location? Should I add this
> servlet to the patch? What about web.xml? Is it generated by xdoclet?
yes, we will need to use the new RSD url. i will handle the rest as far as adding the RSDServlet and rsd.vm.
-- Allen
>
> -- Sean
>
> Allen Gilliland wrote:
> > I hacked up a very simple RSDServlet which uses velocity and I am willing to commit it if everyone is in agreement. This will add a new servlet mapped to /rsd/*, so that you can get the rsd for a weblog via /rsd/<handle>.
> >
> > Here's the code if anyone really wants to take a look ...
> >
> > public class RSDServlet extends VelocityServlet {
> >
> > private static Log mLogger = LogFactory.getLog(RSDServlet.class);
> >
> >
> > /**
> > * Process a request for an rsd file.
> > */
> > public Template handleRequest(HttpServletRequest request,
> > HttpServletResponse response,
> > Context ctx)
> > throws IOException {
> >
> > Template template = null;
> > WeblogRequest weblogRequest = null;
> > WebsiteData weblog = null;
> >
> > // first off lets parse the incoming request and validate it
> > try {
> > weblogRequest = new WeblogRequest(request);
> >
> > // now make sure the specified weblog really exists
> > UserManager userMgr = RollerFactory.getRoller().getUserManager();
> > weblog = userMgr.getWebsiteByHandle(weblogRequest.getWeblogHandle(), Boolean.TRUE);
> >
> > } catch(InvalidRequestException ire) {
> > // An error initializing the request is considered to be a 404
> > response.sendError(HttpServletResponse.SC_NOT_FOUND);
> > request.setAttribute("DisplayException", ire);
> > mLogger.error("Bad Request: "+ire.getMessage());
> >
> > return null;
> >
> > } catch(RollerException re) {
> > // error looking up the weblog, we assume it doesn't exist
> > response.sendError(HttpServletResponse.SC_NOT_FOUND);
> > request.setAttribute("DisplayException", re);
> > mLogger.warn("Unable to lookup weblog ["+
> > weblogRequest.getWeblogHandle()+"] "+re.getMessage());
> >
> > return null;
> > }
> >
> >
> > // request appears to be valid, lets render
> > try {
> >
> > // setup context
> > ctx.put("website", weblog);
> >
> > RollerContext rollerContext = new RollerContext();
> > ctx.put("absBaseURL", rollerContext.getAbsoluteContextUrl(request));
> >
> > // lookup our rsd template
> > template = getTemplate("/flavors/rsd.vm");
> >
> > // make sure response content type is properly set
> > response.setContentType("application/rsd+xml");
> >
> > } catch(ResourceNotFoundException rnfe ) {
> >
> > response.sendError(HttpServletResponse.SC_NOT_FOUND);
> > request.setAttribute("DisplayException", rnfe);
> > mLogger.warn("ResourceNotFound: "+ request.getRequestURL());
> > mLogger.debug(rnfe);
> > } catch(Exception e) {
> >
> > response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
> > request.setAttribute("DisplayException", e);
> > mLogger.error("Unexpected exception", e);
> > }
> >
> > return template;
> > }
> >
> > }
> >
> >
> > and the rsd.vm file ...
> >
> > <rsd version="1.0">
> > <service>
> > <engineName>Roller Weblogger</engineName>
> > <engineLink>http://www.rollerweblogger.org/</engineLink>
> > <homePageLink>${absBaseURL}/page/${website.handle}/</homePageLink>
> > <apis>
> > <api name="blogger" preferred="false"
> > apiLink="${absBaseURL}/xmlrpc"
> > blogID="${website.handle}"/>
> > <api name="metaWeblog" preferred="true"
> > apiLink="${absBaseURL}/xmlrpc"
> > blogID="${website.handle}"/>
> > </apis>
> > </service>
> > </rsd>
> >
> > -- Allen
> >
> >
> > On Wed, 2005-12-14 at 20:46, Sean Gilligan wrote:
> >> Allen Gilliland wrote:
> >>> I don't think the patch came through because I'm guessing the mailing
> >>> list is stripping all attachments :/
> >> I attached the patch to ROL-930 in JIRA:
> >> http://opensource2.atlassian.com/projects/roller/browse/ROL-930
> >> rather than to the mailing list.
> >>
> >>> Also, I want to be fairly careful about the decision to just add the RSD
> >>> support to the FlavorServlet. I still prefer the RSD servlet idea.
> >> I think the RSDServlet idea makes sense, but I'm a Roller beginner and
> >> have no real experience with Struts. (I'm migrating my web-layer skills
> >> from Turbine to SpringMVC)
> >>
> >> In any event, someone could commit the patch I've submitted and that
> >> would enable RSD and update the theme templates. Separately (and
> >> hopefully before 2.1) someone could create an RSDServlet (or
> >> RSDController, etc.) as a more lightweight solution.
> >>
> >> I'm willing to write the RSDServlet (or controller/action) if that's
> >> what people decide is necessary to get the RSD patch committed, but I'm
> >> a little hesitant to dive into Roller web.xml/struts/web configuration
> >> if I can avoid it ;)
> >>
> >> -- Sean
> >
> >
> >
>
Re: Patch submitted for RSD, RSS, etc.
Posted by Sean Gilligan <se...@msgilligan.com>.
Thanks, Allen. Looks good! My only suggestion for a possible change is
that perhaps the rsd.vm file shouldn't live in the "flavors" directory,
since it is no longer being served by the FlavorServlet?
Should I resubmit my patch with website.vm referencing the new RSD url?
Should I also move rsd.vm to another location? Should I add this
servlet to the patch? What about web.xml? Is it generated by xdoclet?
-- Sean
Allen Gilliland wrote:
> I hacked up a very simple RSDServlet which uses velocity and I am willing to commit it if everyone is in agreement. This will add a new servlet mapped to /rsd/*, so that you can get the rsd for a weblog via /rsd/<handle>.
>
> Here's the code if anyone really wants to take a look ...
>
> public class RSDServlet extends VelocityServlet {
>
> private static Log mLogger = LogFactory.getLog(RSDServlet.class);
>
>
> /**
> * Process a request for an rsd file.
> */
> public Template handleRequest(HttpServletRequest request,
> HttpServletResponse response,
> Context ctx)
> throws IOException {
>
> Template template = null;
> WeblogRequest weblogRequest = null;
> WebsiteData weblog = null;
>
> // first off lets parse the incoming request and validate it
> try {
> weblogRequest = new WeblogRequest(request);
>
> // now make sure the specified weblog really exists
> UserManager userMgr = RollerFactory.getRoller().getUserManager();
> weblog = userMgr.getWebsiteByHandle(weblogRequest.getWeblogHandle(), Boolean.TRUE);
>
> } catch(InvalidRequestException ire) {
> // An error initializing the request is considered to be a 404
> response.sendError(HttpServletResponse.SC_NOT_FOUND);
> request.setAttribute("DisplayException", ire);
> mLogger.error("Bad Request: "+ire.getMessage());
>
> return null;
>
> } catch(RollerException re) {
> // error looking up the weblog, we assume it doesn't exist
> response.sendError(HttpServletResponse.SC_NOT_FOUND);
> request.setAttribute("DisplayException", re);
> mLogger.warn("Unable to lookup weblog ["+
> weblogRequest.getWeblogHandle()+"] "+re.getMessage());
>
> return null;
> }
>
>
> // request appears to be valid, lets render
> try {
>
> // setup context
> ctx.put("website", weblog);
>
> RollerContext rollerContext = new RollerContext();
> ctx.put("absBaseURL", rollerContext.getAbsoluteContextUrl(request));
>
> // lookup our rsd template
> template = getTemplate("/flavors/rsd.vm");
>
> // make sure response content type is properly set
> response.setContentType("application/rsd+xml");
>
> } catch(ResourceNotFoundException rnfe ) {
>
> response.sendError(HttpServletResponse.SC_NOT_FOUND);
> request.setAttribute("DisplayException", rnfe);
> mLogger.warn("ResourceNotFound: "+ request.getRequestURL());
> mLogger.debug(rnfe);
> } catch(Exception e) {
>
> response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
> request.setAttribute("DisplayException", e);
> mLogger.error("Unexpected exception", e);
> }
>
> return template;
> }
>
> }
>
>
> and the rsd.vm file ...
>
> <rsd version="1.0">
> <service>
> <engineName>Roller Weblogger</engineName>
> <engineLink>http://www.rollerweblogger.org/</engineLink>
> <homePageLink>${absBaseURL}/page/${website.handle}/</homePageLink>
> <apis>
> <api name="blogger" preferred="false"
> apiLink="${absBaseURL}/xmlrpc"
> blogID="${website.handle}"/>
> <api name="metaWeblog" preferred="true"
> apiLink="${absBaseURL}/xmlrpc"
> blogID="${website.handle}"/>
> </apis>
> </service>
> </rsd>
>
> -- Allen
>
>
> On Wed, 2005-12-14 at 20:46, Sean Gilligan wrote:
>> Allen Gilliland wrote:
>>> I don't think the patch came through because I'm guessing the mailing
>>> list is stripping all attachments :/
>> I attached the patch to ROL-930 in JIRA:
>> http://opensource2.atlassian.com/projects/roller/browse/ROL-930
>> rather than to the mailing list.
>>
>>> Also, I want to be fairly careful about the decision to just add the RSD
>>> support to the FlavorServlet. I still prefer the RSD servlet idea.
>> I think the RSDServlet idea makes sense, but I'm a Roller beginner and
>> have no real experience with Struts. (I'm migrating my web-layer skills
>> from Turbine to SpringMVC)
>>
>> In any event, someone could commit the patch I've submitted and that
>> would enable RSD and update the theme templates. Separately (and
>> hopefully before 2.1) someone could create an RSDServlet (or
>> RSDController, etc.) as a more lightweight solution.
>>
>> I'm willing to write the RSDServlet (or controller/action) if that's
>> what people decide is necessary to get the RSD patch committed, but I'm
>> a little hesitant to dive into Roller web.xml/struts/web configuration
>> if I can avoid it ;)
>>
>> -- Sean
>
>
>
Re: Patch submitted for RSD, RSS, etc.
Posted by Dave Johnson <da...@rollerweblogger.org>.
+1
And big thanks to Sean for investigating this important new feature and
submitting the patch.
- Dave
On Dec 16, 2005, at 2:44 PM, Allen Gilliland wrote:
> I hacked up a very simple RSDServlet which uses velocity and I am
> willing to commit it if everyone is in agreement. This will add a new
> servlet mapped to /rsd/*, so that you can get the rsd for a weblog via
> /rsd/<handle>.
>
> Here's the code if anyone really wants to take a look ...
>
> public class RSDServlet extends VelocityServlet {
>
> private static Log mLogger = LogFactory.getLog(RSDServlet.class);
>
>
> /**
> * Process a request for an rsd file.
> */
> public Template handleRequest(HttpServletRequest request,
> HttpServletResponse response,
> Context ctx)
> throws IOException {
>
> Template template = null;
> WeblogRequest weblogRequest = null;
> WebsiteData weblog = null;
>
> // first off lets parse the incoming request and validate it
> try {
> weblogRequest = new WeblogRequest(request);
>
> // now make sure the specified weblog really exists
> UserManager userMgr =
> RollerFactory.getRoller().getUserManager();
> weblog =
> userMgr.getWebsiteByHandle(weblogRequest.getWeblogHandle(),
> Boolean.TRUE);
>
> } catch(InvalidRequestException ire) {
> // An error initializing the request is considered to be a
> 404
> response.sendError(HttpServletResponse.SC_NOT_FOUND);
> request.setAttribute("DisplayException", ire);
> mLogger.error("Bad Request: "+ire.getMessage());
>
> return null;
>
> } catch(RollerException re) {
> // error looking up the weblog, we assume it doesn't exist
> response.sendError(HttpServletResponse.SC_NOT_FOUND);
> request.setAttribute("DisplayException", re);
> mLogger.warn("Unable to lookup weblog ["+
> weblogRequest.getWeblogHandle()+"]
> "+re.getMessage());
>
> return null;
> }
>
>
> // request appears to be valid, lets render
> try {
>
> // setup context
> ctx.put("website", weblog);
>
> RollerContext rollerContext = new RollerContext();
> ctx.put("absBaseURL",
> rollerContext.getAbsoluteContextUrl(request));
>
> // lookup our rsd template
> template = getTemplate("/flavors/rsd.vm");
>
> // make sure response content type is properly set
> response.setContentType("application/rsd+xml");
>
> } catch(ResourceNotFoundException rnfe ) {
>
> response.sendError(HttpServletResponse.SC_NOT_FOUND);
> request.setAttribute("DisplayException", rnfe);
> mLogger.warn("ResourceNotFound: "+
> request.getRequestURL());
> mLogger.debug(rnfe);
> } catch(Exception e) {
>
>
> response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
> request.setAttribute("DisplayException", e);
> mLogger.error("Unexpected exception", e);
> }
>
> return template;
> }
>
> }
>
>
> and the rsd.vm file ...
>
> <rsd version="1.0">
> <service>
> <engineName>Roller Weblogger</engineName>
> <engineLink>http://www.rollerweblogger.org/</engineLink>
> <homePageLink>${absBaseURL}/page/${website.handle}/</homePageLink>
> <apis>
> <api name="blogger" preferred="false"
> apiLink="${absBaseURL}/xmlrpc"
> blogID="${website.handle}"/>
> <api name="metaWeblog" preferred="true"
> apiLink="${absBaseURL}/xmlrpc"
> blogID="${website.handle}"/>
> </apis>
> </service>
> </rsd>
>
> -- Allen
>
>
> On Wed, 2005-12-14 at 20:46, Sean Gilligan wrote:
>> Allen Gilliland wrote:
>>> I don't think the patch came through because I'm guessing the mailing
>>> list is stripping all attachments :/
>>
>> I attached the patch to ROL-930 in JIRA:
>> http://opensource2.atlassian.com/projects/roller/browse/ROL-930
>> rather than to the mailing list.
>>
>>>
>>> Also, I want to be fairly careful about the decision to just add the
>>> RSD
>>> support to the FlavorServlet. I still prefer the RSD servlet idea.
>>
>> I think the RSDServlet idea makes sense, but I'm a Roller beginner and
>> have no real experience with Struts. (I'm migrating my web-layer
>> skills
>> from Turbine to SpringMVC)
>>
>> In any event, someone could commit the patch I've submitted and that
>> would enable RSD and update the theme templates. Separately (and
>> hopefully before 2.1) someone could create an RSDServlet (or
>> RSDController, etc.) as a more lightweight solution.
>>
>> I'm willing to write the RSDServlet (or controller/action) if that's
>> what people decide is necessary to get the RSD patch committed, but
>> I'm
>> a little hesitant to dive into Roller web.xml/struts/web configuration
>> if I can avoid it ;)
>>
>> -- Sean
>
Re: Patch submitted for RSD, RSS, etc.
Posted by Allen Gilliland <Al...@Sun.COM>.
I hacked up a very simple RSDServlet which uses velocity and I am willing to commit it if everyone is in agreement. This will add a new servlet mapped to /rsd/*, so that you can get the rsd for a weblog via /rsd/<handle>.
Here's the code if anyone really wants to take a look ...
public class RSDServlet extends VelocityServlet {
private static Log mLogger = LogFactory.getLog(RSDServlet.class);
/**
* Process a request for an rsd file.
*/
public Template handleRequest(HttpServletRequest request,
HttpServletResponse response,
Context ctx)
throws IOException {
Template template = null;
WeblogRequest weblogRequest = null;
WebsiteData weblog = null;
// first off lets parse the incoming request and validate it
try {
weblogRequest = new WeblogRequest(request);
// now make sure the specified weblog really exists
UserManager userMgr = RollerFactory.getRoller().getUserManager();
weblog = userMgr.getWebsiteByHandle(weblogRequest.getWeblogHandle(), Boolean.TRUE);
} catch(InvalidRequestException ire) {
// An error initializing the request is considered to be a 404
response.sendError(HttpServletResponse.SC_NOT_FOUND);
request.setAttribute("DisplayException", ire);
mLogger.error("Bad Request: "+ire.getMessage());
return null;
} catch(RollerException re) {
// error looking up the weblog, we assume it doesn't exist
response.sendError(HttpServletResponse.SC_NOT_FOUND);
request.setAttribute("DisplayException", re);
mLogger.warn("Unable to lookup weblog ["+
weblogRequest.getWeblogHandle()+"] "+re.getMessage());
return null;
}
// request appears to be valid, lets render
try {
// setup context
ctx.put("website", weblog);
RollerContext rollerContext = new RollerContext();
ctx.put("absBaseURL", rollerContext.getAbsoluteContextUrl(request));
// lookup our rsd template
template = getTemplate("/flavors/rsd.vm");
// make sure response content type is properly set
response.setContentType("application/rsd+xml");
} catch(ResourceNotFoundException rnfe ) {
response.sendError(HttpServletResponse.SC_NOT_FOUND);
request.setAttribute("DisplayException", rnfe);
mLogger.warn("ResourceNotFound: "+ request.getRequestURL());
mLogger.debug(rnfe);
} catch(Exception e) {
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
request.setAttribute("DisplayException", e);
mLogger.error("Unexpected exception", e);
}
return template;
}
}
and the rsd.vm file ...
<rsd version="1.0">
<service>
<engineName>Roller Weblogger</engineName>
<engineLink>http://www.rollerweblogger.org/</engineLink>
<homePageLink>${absBaseURL}/page/${website.handle}/</homePageLink>
<apis>
<api name="blogger" preferred="false"
apiLink="${absBaseURL}/xmlrpc"
blogID="${website.handle}"/>
<api name="metaWeblog" preferred="true"
apiLink="${absBaseURL}/xmlrpc"
blogID="${website.handle}"/>
</apis>
</service>
</rsd>
-- Allen
On Wed, 2005-12-14 at 20:46, Sean Gilligan wrote:
> Allen Gilliland wrote:
> > I don't think the patch came through because I'm guessing the mailing
> > list is stripping all attachments :/
>
> I attached the patch to ROL-930 in JIRA:
> http://opensource2.atlassian.com/projects/roller/browse/ROL-930
> rather than to the mailing list.
>
> >
> > Also, I want to be fairly careful about the decision to just add the RSD
> > support to the FlavorServlet. I still prefer the RSD servlet idea.
>
> I think the RSDServlet idea makes sense, but I'm a Roller beginner and
> have no real experience with Struts. (I'm migrating my web-layer skills
> from Turbine to SpringMVC)
>
> In any event, someone could commit the patch I've submitted and that
> would enable RSD and update the theme templates. Separately (and
> hopefully before 2.1) someone could create an RSDServlet (or
> RSDController, etc.) as a more lightweight solution.
>
> I'm willing to write the RSDServlet (or controller/action) if that's
> what people decide is necessary to get the RSD patch committed, but I'm
> a little hesitant to dive into Roller web.xml/struts/web configuration
> if I can avoid it ;)
>
> -- Sean
Re: Patch submitted for RSD, RSS, etc.
Posted by Sean Gilligan <se...@msgilligan.com>.
Allen Gilliland wrote:
> I don't think the patch came through because I'm guessing the mailing
> list is stripping all attachments :/
I attached the patch to ROL-930 in JIRA:
http://opensource2.atlassian.com/projects/roller/browse/ROL-930
rather than to the mailing list.
>
> Also, I want to be fairly careful about the decision to just add the RSD
> support to the FlavorServlet. I still prefer the RSD servlet idea.
I think the RSDServlet idea makes sense, but I'm a Roller beginner and
have no real experience with Struts. (I'm migrating my web-layer skills
from Turbine to SpringMVC)
In any event, someone could commit the patch I've submitted and that
would enable RSD and update the theme templates. Separately (and
hopefully before 2.1) someone could create an RSDServlet (or
RSDController, etc.) as a more lightweight solution.
I'm willing to write the RSDServlet (or controller/action) if that's
what people decide is necessary to get the RSD patch committed, but I'm
a little hesitant to dive into Roller web.xml/struts/web configuration
if I can avoid it ;)
-- Sean
Re: Themes: Contributing
Posted by Allen Gilliland <Al...@Sun.COM>.
On Thu, 2006-01-05 at 14:09, David M Johnson wrote:
> Greg,
>
> Some of our design gurus at Sun are interested in helping out with
> some implementation pointers help you get started with theme
> development. Would you be interested in a having a short tele-con to
> kick things off?
>
> Regading guidelies: the only guidelines we have now are in the user
> guide about packaging themes, I think that's about all we have. See
> section 6.4.
>
> http://people.apache.org/~snoopdave/doc_drafts/roller-user-guide-210.pdf
I sent a response back before Christmas about some aspects of our themes implementation that could probably use some additional thought. I don't think it will really affect how the themes are created, but we may want to think about themes are packaged and deployed.
>
> There are also a couple of proposals on the table:
>
> I believe this one is already in Roller (right Allen?)
> http://rollerweblogger.org/wiki/Wiki.jsp?
> page=Proposal_StandardizedPageNames
>
> And this one is still pending?
> http://rollerweblogger.org/wiki/Wiki.jsp?
> page=Proposal_StandardizedTemplates
actually, those are the same thing and yes, i've already commited that code. I actually scaled back the implementation so that we only do 2 things ...
1. manually force all weblogs to use "Weblog" as the default page link. this is done via the Roller 2.1 upgrade procedure.
2. lock certain templates so they can't be changed. those include Weblog, _css, _day, _decorator. As of Roller 2.1 a user can only edit the contents of those templates, not the name, description, or link. Users also can't delete those templates either.
this shouldn't affect anything either, just as long as they don't deviate from our standard template names.
-- Allen
>
> - Dave
>
>
>
>
> On Dec 26, 2005, at 5:40 PM, Greg Hamer wrote:
>
> > Dear Devs,
> >
> > I am on the advisory board for a design school. I would like to
> > propose as a student project for upcoming semesters that students
> > create Roller theme pages (e.g. Weblog.vm, _day.vm, etc.)
> >
> > My question to you is does Roller accept new stock themes that
> > would be included in the future Roller release distributions? If
> > so, could you please sketch out for me what process students should
> > follow to submit their themes? Also, could you sketch guidelines
> > that might be used in determining if a theme might be acceptable or
> > unacceptable?
> >
> > Thank you again for your great work. I hope that you are having an
> > enjoyable holiday. Best regards for good health and prosperity in
> > the new year.
> >
> > g
>
Re: Themes: Contributing
Posted by Greg Hamer <ro...@gmail.com>.
Dave,
Regarding a telecon, no problem. With a day or two's advance notice, I can clear my schedule for whatever time is convenient for the rest of the participants. fyi ... I am on Pacific Standard Time.
Ultimately, I think the result of our effort could be an expanded version of the current User Guide section on "Customizing your weblog's theme".
My target audience is design students. For them I believe that Roller themes present a unique but valuable challenge. Unique in that from a design perspective, designing with Velocimacros and multipage templates (Weblog, _day, etc) adds a level of complexity design students may not have yet encountered. Valuable in that designing for dynamic sites is an important skill (versus, say, the designs at the highly regarded csszengarden.com which uses static content), and contributing to an open source project will get work from their portfolio into the public domain (i.e. a nice reference).
btw ... both Allen and Matt's comments from last week would definately be reflected in process.
Please let me know when will be a convenient time for the call.
Best regards,
g
----- Original Message -----
From: "David M Johnson" <Da...@Sun.COM>
To: "Greg Hamer" <ro...@gmail.com>
Cc: "Linda Skrocki" <Li...@Sun.COM>; <ro...@incubator.apache.org>
Sent: Thursday, January 05, 2006 2:09 PM
Subject: Re: Themes: Contributing
Greg,
Some of our design gurus at Sun are interested in helping out with some implementation pointers help you get started with theme development. Would you be interested in a having a short tele-con to kick things off?
Regarding guidelines: the only guidelines we have now are in the user guide about packaging themes, I think that's about all we have. See section 6.4.
http://people.apache.org/~snoopdave/doc_drafts/roller-user-guide-210.pdf
There are also a couple of proposals on the table:
I believe this one is already in Roller (right Allen?)
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_StandardizedPageNames
And this one is still pending?
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_StandardizedTemplates
- Dave
On Dec 26, 2005, at 5:40 PM, Greg Hamer wrote:
> Dear Devs,
>
> I am on the advisory board for a design school. I would like to
> propose as a student project for upcoming semesters that students
> create Roller theme pages (e.g. Weblog.vm, _day.vm, etc.)
>
> My question to you is does Roller accept new stock themes that
> would be included in the future Roller release distributions? If
> so, could you please sketch out for me what process students should
> follow to submit their themes? Also, could you sketch guidelines
> that might be used in determining if a theme might be acceptable or
> unacceptable?
>
> Thank you again for your great work. I hope that you are having an
> enjoyable holiday. Best regards for good health and prosperity in
> the new year.
>
> g
Re: Themes: Contributing
Posted by David M Johnson <Da...@Sun.COM>.
Greg,
Some of our design gurus at Sun are interested in helping out with
some implementation pointers help you get started with theme
development. Would you be interested in a having a short tele-con to
kick things off?
Regading guidelies: the only guidelines we have now are in the user
guide about packaging themes, I think that's about all we have. See
section 6.4.
http://people.apache.org/~snoopdave/doc_drafts/roller-user-guide-210.pdf
There are also a couple of proposals on the table:
I believe this one is already in Roller (right Allen?)
http://rollerweblogger.org/wiki/Wiki.jsp?
page=Proposal_StandardizedPageNames
And this one is still pending?
http://rollerweblogger.org/wiki/Wiki.jsp?
page=Proposal_StandardizedTemplates
- Dave
On Dec 26, 2005, at 5:40 PM, Greg Hamer wrote:
> Dear Devs,
>
> I am on the advisory board for a design school. I would like to
> propose as a student project for upcoming semesters that students
> create Roller theme pages (e.g. Weblog.vm, _day.vm, etc.)
>
> My question to you is does Roller accept new stock themes that
> would be included in the future Roller release distributions? If
> so, could you please sketch out for me what process students should
> follow to submit their themes? Also, could you sketch guidelines
> that might be used in determining if a theme might be acceptable or
> unacceptable?
>
> Thank you again for your great work. I hope that you are having an
> enjoyable holiday. Best regards for good health and prosperity in
> the new year.
>
> g
Re: Requiring email address at signup
Posted by "Matthew P. Schmidt" <ma...@javalobby.org>.
Hmm, it appears that my other suggestion (check existing username) also
exists, but its buried in UserManager.addUser which bubbles up a
RollerException and is turned into an ActionError. A little out of the
way, but still gets the job done.
-Matt
Matt Raible wrote:
>On 12/29/05, Matthew P. Schmidt <ma...@javalobby.org> wrote:
>
>
>>Hi everyone. These days, having an email address is mandatory for most
>>types of services. At JRoller, we had to hack the
>>UserNewAction.validate method to throw an error if the username is
>>already in use or the email address is missing. I would like to propose
>>that we add these two validation requirements to the core. Any
>>objections? If not, I can send the patch.
>>
>>
>
>No objections here. Do you have commit rights yet? If so, just
>commit the change - no need for a patch. ;-)
>
>Matt
>
>(uh, oh, 2 Matt's - I'm going to have to start going by "Raible",
>which I do at most places with 2 Matt's)
>
>
>
>>-Matt
>>
>>
>>
Re: Requiring email address at signup
Posted by "Matthew P. Schmidt" <ma...@javalobby.org>.
Unfortunately, the paperwork hasn't come back yet. So its a patch for
now :)
Matt Raible wrote:
>On 12/29/05, Matthew P. Schmidt <ma...@javalobby.org> wrote:
>
>
>>Hi everyone. These days, having an email address is mandatory for most
>>types of services. At JRoller, we had to hack the
>>UserNewAction.validate method to throw an error if the username is
>>already in use or the email address is missing. I would like to propose
>>that we add these two validation requirements to the core. Any
>>objections? If not, I can send the patch.
>>
>>
>
>No objections here. Do you have commit rights yet? If so, just
>commit the change - no need for a patch. ;-)
>
>Matt
>
>(uh, oh, 2 Matt's - I'm going to have to start going by "Raible",
>which I do at most places with 2 Matt's)
>
>
>
>>-Matt
>>
>>
>>
Re: Requiring email address at signup
Posted by "Matthew P. Schmidt" <ma...@javalobby.org>.
Actually, it looks like UserBaseAction already handles the missing email
address. Bad on me for not checking the superclass :) I'll still
provide the patch for the existing username.
-Matt
Matt Raible wrote:
>On 12/29/05, Matthew P. Schmidt <ma...@javalobby.org> wrote:
>
>
>>Hi everyone. These days, having an email address is mandatory for most
>>types of services. At JRoller, we had to hack the
>>UserNewAction.validate method to throw an error if the username is
>>already in use or the email address is missing. I would like to propose
>>that we add these two validation requirements to the core. Any
>>objections? If not, I can send the patch.
>>
>>
>
>No objections here. Do you have commit rights yet? If so, just
>commit the change - no need for a patch. ;-)
>
>Matt
>
>(uh, oh, 2 Matt's - I'm going to have to start going by "Raible",
>which I do at most places with 2 Matt's)
>
>
>
>>-Matt
>>
>>
>>
Re: Requiring email address at signup
Posted by Matt Raible <mr...@gmail.com>.
On 12/29/05, Matthew P. Schmidt <ma...@javalobby.org> wrote:
> Hi everyone. These days, having an email address is mandatory for most
> types of services. At JRoller, we had to hack the
> UserNewAction.validate method to throw an error if the username is
> already in use or the email address is missing. I would like to propose
> that we add these two validation requirements to the core. Any
> objections? If not, I can send the patch.
No objections here. Do you have commit rights yet? If so, just
commit the change - no need for a patch. ;-)
Matt
(uh, oh, 2 Matt's - I'm going to have to start going by "Raible",
which I do at most places with 2 Matt's)
>
> -Matt
>
Requiring email address at signup
Posted by "Matthew P. Schmidt" <ma...@javalobby.org>.
Hi everyone. These days, having an email address is mandatory for most
types of services. At JRoller, we had to hack the
UserNewAction.validate method to throw an error if the username is
already in use or the email address is missing. I would like to propose
that we add these two validation requirements to the core. Any
objections? If not, I can send the patch.
-Matt
Re: Themes: Contributing
Posted by Allen Gilliland <Al...@Sun.COM>.
I'll second that motion. We are definitely looking to add to our theme
collection, so we'd love to get whatever you guys can come up with.
I think Matt's criteria sound right. One semi-neat suggestion would be
to try and get all the themes to use the same basic html/css framework,
that way it's easier to mix and match css/javascript widgets between themes.
On a bit of a side note, this may also be a good time to make sure our
approach to themes is flushed out. a couple minor things that I don't
particularly like in some of our current themes are ...
1. some themes reference static files (css, js, images). this makes it
very hard to ensure that when someone customizes a theme they are
getting a local copy of all the theme's resources. what ends up
happening is that people have 2 year old themes with links to css and
images which could become broken/changed in the future. it would be
nice if we had a way to keep this from happening.
2. some themes use shared resources (css, js, images). i think this is
even slightly more problematic than #1. i prefer that themes be self
contained.
3. i think we should keep the number of templates to a minimum and avoid
using the "_decorator" template. in my mind, more templates = more
confusing for users.
Also worth considering is our theme distribution system. Would it not
make a bit more sense to move the themes directory outside the webapp
and allow Roller admins to download themes individually or in bundles?
this would make it easier for admins to control what themes are
available on their site without having it tied to the webapp, so app
upgrades would be easier.
Anways, just some thoughts.
-- Allen
Matt Raible wrote:
>I think I can speak for the team and say YES - this sounds like a *great* idea!!
>
>On 12/26/05, Greg Hamer <ro...@gmail.com> wrote:
>
>
>>Dear Devs,
>>
>>I am on the advisory board for a design school. I would like to propose as a student project for upcoming semesters that students create Roller theme pages (e.g. Weblog.vm, _day.vm, etc.)
>>
>>My question to you is does Roller accept new stock themes that would be included in the future Roller release distributions? If so, could you please sketch out for me what process students should follow to submit their themes? Also, could you sketch guidelines that might be used in determining if a theme might be acceptable or unacceptable?
>>
>>
>
>I think the very basic criteria should be:
>
>1. XHTML 1.0 Transitional compliant
>2. CSS 2 Compliant
>3. Good lookin' ;-)
>
>There are validators for the first two. In addition, it should be
>possible for us to convert Photoshop images to XHTML/CSS - but
>obviously the whole ball of wax would make it easier to integrate.
>
>Of course, I'm just one voice in a growing community. ;-)
>
>Matt
>
>
>
>>Thank you again for your great work. I hope that you are having an enjoyable holiday. Best regards for good health and prosperity in the new year.
>>
>> g
>>
>>
>>
Re: Themes: Contributing
Posted by Matt Raible <mr...@gmail.com>.
I think I can speak for the team and say YES - this sounds like a *great* idea!!
On 12/26/05, Greg Hamer <ro...@gmail.com> wrote:
> Dear Devs,
>
> I am on the advisory board for a design school. I would like to propose as a student project for upcoming semesters that students create Roller theme pages (e.g. Weblog.vm, _day.vm, etc.)
>
> My question to you is does Roller accept new stock themes that would be included in the future Roller release distributions? If so, could you please sketch out for me what process students should follow to submit their themes? Also, could you sketch guidelines that might be used in determining if a theme might be acceptable or unacceptable?
I think the very basic criteria should be:
1. XHTML 1.0 Transitional compliant
2. CSS 2 Compliant
3. Good lookin' ;-)
There are validators for the first two. In addition, it should be
possible for us to convert Photoshop images to XHTML/CSS - but
obviously the whole ball of wax would make it easier to integrate.
Of course, I'm just one voice in a growing community. ;-)
Matt
>
> Thank you again for your great work. I hope that you are having an enjoyable holiday. Best regards for good health and prosperity in the new year.
>
> g
>
Themes: Contributing
Posted by Greg Hamer <ro...@gmail.com>.
Dear Devs,
I am on the advisory board for a design school. I would like to propose as a student project for upcoming semesters that students create Roller theme pages (e.g. Weblog.vm, _day.vm, etc.)
My question to you is does Roller accept new stock themes that would be included in the future Roller release distributions? If so, could you please sketch out for me what process students should follow to submit their themes? Also, could you sketch guidelines that might be used in determining if a theme might be acceptable or unacceptable?
Thank you again for your great work. I hope that you are having an enjoyable holiday. Best regards for good health and prosperity in the new year.
g
Re: Patch submitted for RSD, RSS, etc.
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Dec 14, 2005, at 11:06 PM, Allen Gilliland wrote:
> The two examples I think are most relevant are the RollerRequest
> object,
> which in my opinion is a good idea, except that the way it's
> impelemented is a bit too much "all in one." I think the RollerRequest
> can be broken down into smaller more specialized subclasses which would
> be more effective. Another example is the way we setup the Velocity
> Context object, where we basically try and stuff all things that any
> page would want (page, search, flavor, etc) rather than having a
> separate context setup process per function.
>
> As usual, others opinions are welcomed.
For the record, I think your comments about RollerRequest and the
Velocity context are right on target. RollerRequest does WAY too much.
- Dave
Re: Patch submitted for RSD, RSS, etc.
Posted by Allen Gilliland <Al...@Sun.COM>.
I don't think the patch came through because I'm guessing the mailing
list is stripping all attachments :/
Also, I want to be fairly careful about the decision to just add the RSD
support to the FlavorServlet. I still prefer the RSD servlet idea.
My reason is derived mainly from the fact that I believe that there are
various places in Roller where we have tried to squeeze too much
functionality into a small number of classes/objects. There are also
places where we have tried to create generic all purpose code rather
than taking the additional time and effort to separate out functionality
that should be a bit decoupled.
The two examples I think are most relevant are the RollerRequest object,
which in my opinion is a good idea, except that the way it's
impelemented is a bit too much "all in one." I think the RollerRequest
can be broken down into smaller more specialized subclasses which would
be more effective. Another example is the way we setup the Velocity
Context object, where we basically try and stuff all things that any
page would want (page, search, flavor, etc) rather than having a
separate context setup process per function.
I think the RSDServlet is a good place to start to break this habit by
being very lightweight and only hitting the db for things it really
needs, and also by creating it's own velocity context populated with
only the items it needs.
As usual, others opinions are welcomed.
-- Allen
On Wed, 2005-12-14 at 17:50, Sean Gilligan wrote:
> I went ahead and attached an "svn diff" (I'm not sure that's the right
> way to submit a patch, let me know if it isn't) to ROL-930.
>
> This patch fixes ROL-899, ROL-930 and also uses
> #showContentType("text/html; charset=utf-8") in place of a direct <meta>
> tag for consistency between templates.
>
> Further, some files had CRLF instead of LF, so I changed/fixed that, too.
>
> If we later decide to write an RSDServlet, we can change the
> #showRSDLink() macro and the theme templates won't have to change.
>
> Regards,
>
> Sean
>
>