[
https://issues.apache.org/jira/browse/JSPWIKI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17043676#comment-17043676
]
ASF subversion and git services commented on JSPWIKI-120:
---------------------------------------------------------
Commit f44500b650582c9977b871472c15586dad8f5c72 in jspwiki's branch
refs/heads/master from juanpablo
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=f44500b ]
JSPWIKI-120: propagate WikiContext#getEngine() now returns Engine instead of
WikiEngine (9)
> 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
> Priority: Major
> Fix For: 3.0
>
>
> 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 was sent by Atlassian Jira
(v8.3.4#803005)
