Hi Juan Pablo, Would this change make it more "mainstream" to alter the wiki syntax over to MarkDown? I was thinking of inquiring about the state of MarkDown support, looked at the changes necessary to get it to work as the default syntax and thought: no, not ready for prime time.
The reason I ask is that I've been thinking of doing a MarkDown-only wiki. I've been using Ulysses, a nice MarkDown-based editor on OS X, and was thinking it'd be great to be able to directly edit in the same syntax as JSPWiki. I actually contact their support team but it'd be impossible for them to alter their base syntax (it's baked into their API) so it occurred to me to see how hard it would be to alter JSPWiki. If anyone has positive experience using MarkDown in JSPWiki I'd be keen to hear about it. There are of course various flavours of MarkDown so I'd (likely) need to slightly alter the parsing engine to handle Ulysses' particular flavour... Cheers, Murray > https://issues.apache.org/jira/browse/JSPWIKI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000298#comment-17000298 > ] > > Juan Pablo Santos RodrÃguez commented on JSPWIKI-120: > ----------------------------------------------------- > > changes proposed on ML: > > {quote} > Move from WikiEngine to PageManager: > * void deletePage( final String pageName ) > * void deleteVersion( final WikiPage page ) > * String getCurrentProvider() > * String getCurrentProviderInfo() > * WikiPage getPage( String pagereq ) > * WikiPage getPage( String pagereq, int version ) > * int getPageCount() (already there as getTotalPageCount(), so it can get > deleted) > * String getPureText( String page, int version ) > * String getPureText( WikiPage page ) > * Set< WikiPage > getRecentChanges() > * String getText( String page ) > * String getText( String page, int version ) > * String getText( WikiContext context, WikiPage page ) > * List< ? extends WikiPage > getVersionHistory( String page ) > * boolean pageExists( String page ) > * boolean pageExists( String page, int version ) > * boolean pageExists( WikiPage page ) > * void saveText( WikiContext context, String text ) > > Move from WikiEngine to PageRenamer: > * String renamePage( WikiContext context, String renameFrom, String > renameTo, boolean changeReferrers ) > > Move from WikiEngine to ReferenceManager: > * Collection< String > scanWikiLinks( WikiPage page, String pagedata ) > * void updateReferences( WikiPage page ) > > Move from WikiEngine to RenderingManager: > * String beautifyTitle( String title ) > * String beautifyTitleNoBreak( String title ) > * String decodeName( final String pagerequest ) > * String encodeName( String pagename ) > * String getHTML( String page ) > * String getHTML( String pagename, int version ) > * String getHTML( WikiContext context, WikiPage page ) > * String textToHTML( WikiContext context, String pagedata, > StringTransmutator localLinkHook, StringTransmutator extLinkHook ) > * String textToHTML( WikiContext context, String pagedata, > StringTransmutator localLinkHook, StringTransmutator extLinkHook, > StringTransmutator attLinkHook ) > * String textToHTML( WikiContext context, String pagedata, > StringTransmutator localLinkHook, StringTransmutator extLinkHook, > StringTransmutator attLinkHook, boolean parseAccessRules, boolean > justParse ) > > Move from WikiEngine to HttpUtil: > * String safeGetQueryString( final HttpServletRequest request ) > > Move from WikiEngine to DifferenceManager: > * String getDiff( WikiContext context, int version1, int version2 ) > > Move from WikiEngine to VariableManager: > * String getVariable( WikiContext context, String name ) > > Extract new WikiEngineProperties enum with WikiEngine's public static > final String PROP_* and public static final String DEFAULT_ constants > > WikiEngine would retain all the remaining methods. The following public > API / Interface could be extracted from there, which would focus mainly on > static stuff: > > Configuration > * Collection< String > getAllInlinedImagePatterns() > * Collection< String > getAllInterWikiLinks() > * String getApplicationName() > * String getBaseURL() > * Charset getContentEncoding() > * String getFrontPage() > * String getGlobalRSSURL() > * String getRequiredProperty( Properties props, String key ) throws > NoRequiredPropertyException (maybe throw another kind of exception and > move it back to TextUtils, where it initially was?) > * String getRootPath() > * ServletContext getServletContext() > * Date getStartTime() > * String getTemplateDir() > * Properties getWikiProperties() > * String getWorkDir() > > DI methods [1] > * all XYZ getXYZManager methods > > Context creation > * WikiContext createContext( final HttpServletRequest request, final > String requestContext ) > > WikiEngine attributes > * Object getAttribute( String key ) > * Object removeAttribute( String key ) > * void setAttribute( String key, Object value ) > > URL creation [2] > * CommandResolver getCommandResolver() > * getURL( final String context, String pageName, final String params, > final boolean absolute ) > * String getInterWikiURL( String wikiName ) > * String getViewURL( String pageName ) > * String getRedirectURL( final WikiContext context ) (seems unused?) > * String getFinalPageName( String page ) > * String getSpecialPageReference( String original ) (unused?) > > Event Listeners / WatchDog related operations: > * void addWikiEventListener( WikiEventListener listener ) > * void removeWikiEventListener( WikiEventListener listener ) > * WatchDog getCurrentWatchDog() > > [1]: Instead of exposing each getWhateverManager(), I was more thinking of > having one getManager( Class managerClass ) method at the public API > level, whereas the concrete class would retain all the getXYZManager, in > order to not make an even more breaking change > [2]: perhaps these should be moved into WikiContext ? > {quote} > >> 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) > > ........................................................................... Murray Altheim <murray18 at altheim dot com> = = === http://www.altheim.com/murray/ === === = = === In the evening The rice leaves in the garden Rustle in the autumn wind That blows through my reed hut. -- Minamoto no Tsunenobu
