[
https://issues.apache.org/jira/browse/JSPWIKI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557905#action_12557905
]
Andrew Jaquith commented on JSPWIKI-120:
----------------------------------------
This should be something we address in 3.0.
As it happens, the early work I've done on modeling enhancements needed to
support Stripes suggests fairly strongly that we need to break WikiContext up
quite a bit, to accomodate activities that aren't page related. For example,
admin activities, group and user activities, etc. Right now we're overloading
WikiContext with all these things. The overloading is manifesting itself in odd
ways, such as when we see the page "Main" pop up when creating groups. (Janne
knows why this is, I'm sure, and I do also, but it might not be intuitively
obvious why to anyone else who hasn't spent as much time with the code as we
have...)
So -- that's a long way of saying, YES, we should make WikiContext an
interface. I'd like the concrete classes to roughly follow the existing
Permission types (which would provide some cool symmetry...)
For example:
- PageActionBean (implements page-related WikiContexts, and require
PagePermissions to run)
- WikiActionBean (implements group/user/registraton/profile, and require
WikiPermissions to run)
The abstract superclass for both, logically, would be AbstractWikiContext.
> Separate rendering engine from core
> -----------------------------------
>
> Key: JSPWIKI-120
> URL: https://issues.apache.org/jira/browse/JSPWIKI-120
> Project: JSPWiki
> Issue Type: New Feature
> Components: Core & storage
> Reporter: Janne Jalkanen
>
> Quite a few people have shown up recently on the mailing list and have
> expressed a wish to separate the rendering engine from the core itself, so
> that they wouldn't need so much baggage with the engine.
> Unfortunately, this is quite difficult, as the rendering engine does rely on
> quite a few bits from the WikiEngine instance, for example URL generation and
> checking whether a page/attachment exists or not, as well as settings.
> However, these things could be enumerated and isolated to a RenderingContext
> interface. Then, anyone who would like to get their own engine would need to
> implement this interface.
> It may mean that WikiEngine and WikiContext might need to become interfaces
> as well. However, that might not be such a bad thing, as it would give a
> more stable developer API. Then we would have a three-layered architecture,
> where one layer (WikiEngine) takes care of static stuff, WikiContext contains
> per-request data, and RenderingContext provides the bits and pieces which are
> part of HTML generation.
> At any rate, this requires more thinking. Probably not going to happen
> before 3.0 anyway.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
