Does anyone have an example of a custom made Renderer for xwiki rendering framework? I want to do a conversion from JSPWiki to XHTML but the default result xwiki generates is not sufficient. I need to apply some logic that inspects siblings/children in the intermediate tree.
Debugged the xwiki code what gave me the idea there is a strong seperation between parsing (generates a tree) and rendering. Think solution has to come in the rendering phase
Thx
Tom
If you want to modify the tree, what you want is probably more a custom translation than a renderer actually. Renderes receive events in a streemed way so it's not always easy to do somthing depending on following events even if doable.
For transformations you can look at http://rendering.xwiki.org/xwiki/bin/view/Main/Extending#HAddinganewTransformation. You can also simply use the parser modify the generated XDOM and then render it, creating a translation is generally needed when you don't write yourself the code that parser and renderer.
If you still want to do it as a custom renderer the simplest it probably to extend the XHTML renderer and add you stuff, you have an example of extended XHTML renderer in https://github.com/xwiki/xwiki-rendering/tree/master/xwiki-rendering-syntaxes/xwiki-rendering-syntax-annotatedxhtml (add annotation in the generated XHTML content using XML comments).
Java world has few dead wiki renderers high positioned in google. I use info.bliki.wiki many years, I'm fascinated with high quality of object design
Related
I want to build a CMS/Wiki, I would like to make it with HTML5.
Unfortunately I have been looking for a Wiki rendering engine that could take as input Creole 1.0 syntax and render it as HTML5, Can anyone point me to a library for this purpose?
My second option is to write a renderer for XWiki to support HTML5. Any ideas of how to develop such thing?
The XWiki Rendering engine already supports Creole 1.0 as input syntax, and the output conforms to their recommended HTML output, including the <pre> and <tt> tags for verbatim text (one for block, one for inline). Most of this HTML will be valid HTML5 as well, except for the tt tag which has been removed.
tt was perceived as a purely stylistic tag, and semantically more meaningful tags like kbd, samp, code and var had been available for a long time. The problem is that there are too many alternatives available, so it's hard to pick just one tag to represent correctly (from a semantical POV) all the things that tt is being used for. Should we add 4 different verbatim syntaxes to Creole? Or should we just use code everywhere and ignore its semantics, making it the new tt? Or maybe use pre both for inline and block content, and change the CSS so that it's not always a block element?
Anyway, in order to implement a new html/5.0 syntax renderer, you'd probably have to copy the xhtml module, change most of the classes to just inherit their xhtml/1.0 equivalent, except for XHTMLChainingRenderer where you should alter the way beginFormat and endFormat behave. You should also make an HTML5 parser, so also extend the XHTMLParser class and add another handler for code tags (we should probably do this by default, since it's a valid XHTML tag that we're currently ignoring).
I'm interested in the Tapestry framework put have some problems with it due to several reasons:
The output I have to generate has to be XML. According to http://tapestry.apache.org/content-type-and-markup.html this is no big deal.
But when it comes down to use actionlink, components or all the other Tapestry goodies, the resulting code should not be anchor or div but some custom xml elements/attributes.
Is it possible to archieve this without alot of pain?
Workarounds or insides to the background mechanismn of Tapestry are welcome.
while actionlink will always render as an anchor (a) tag, the Any component can render as any arbitrary xml element, and it and many other tapestry components will render arbitrary (informal) parameters depending on their definition.
for example, (assuming you have a java method called 'getTheTime' in your class, mine returns System.currentTimeMillis())
<xyz t:type="actionlink" t:id="someaction">
a element</xyz>
<xyz t:type="any"
attribute1="${theTime}"
attribute2="prop:theTime"
attribute3="theTime">
xyz element</xyz>
will render as:
a element
<xyz attribute1="1338418847753" attribute2="1338418847753"
attribute3="theTime">xyz element</xyz>
In order to get a combination of the two, you will need to roll your own component. This is pretty simple once you understand tapestry a little better.
Have a look at the source of ActionLink.java (and its super classes) and you should be able to figure it out.
I have a web-app in Java, Spring, Struts 2 and Hibernate, that servers multiple clients. Each client with multiple users. To create a personal feel for each client, i would like to customize the header for each client.
I'm using sitemesh as decorator, and am looking for tips or examples or someone who can point me in the right direction as to how to acomplish this in the best practice.
What would you think? Should i just code it direct in the header.jsp? Extracting the info about the logged in user and from that create a custom header by code? Or is there a more clever solution out there?
Thanks!
Update:
To further clearify what i want:
Different properties-files for each client is not an option. We are looking at potentionally hundreds of clients. It needs to be database-driven. But thats the easy part. There is no problem storing the information in db and extracting it when needed.
What im trying to figure out is if there is some sort of standard way of doing this. Some sort of filter or Action that is run before the sitemesh decorator that will provide the decorator with the correct info?
Struts2 provides application scope, for variables which are global to the application.
Load all the customer specific strings into #application scope (I would use spring to do this when the application starts up). From there referencing the strings would be pretty obvious: #application.greeting I don't like the idea of using an interceptor because there is nothing to intercept. I would say for what you are doing application scope is the perfect place. If it is a single client system I can see no reason why anything would be stored in application scope.
Aside: Tiles uses a different template paradigm than site mesh, and they have slightly different purposes. As such the two can be complimentary. Tiles relying on XML definitions can have it's definitions stored in a DB and is definitely less computationally intensive, however where there is interplay between different UI components... or disparate elements appearing on the page you need to use sitemesh. So for basic template needs tiles does everything and is quite easy to understand but say you wanted to make add a certain widget in the middle of the page which relies on JS which needs to be added to the header it would be tricky to do this in Tiles (although the obvious solution is to just roll the JS functionality into one JS file for all possible uses in a particular part of the site).
Asside 2: By using a view technology such as velocity or freemarker in conjunction with tiles it is conceivable to move the entire view layer into a database. I just thought I would mention that as for some maintenance issues that could be extremely beneficial.
Sitemesh makes it's decisions about what decoration to use based upon the requested URL string, so unless you have a reference to the client in every url - either as part of the main url string or as a known parameter, then Sitemesh out of the box is not going to help.
This leaves a few possibilities to achieve what you want;
1) Write a filter that runs before Sitemesh that adds, for example, "&clientId="xx" to every incoming request.
2) Dive into the source code for Sitemesh & look for where Sitemesh finally makes it's decision about which decorators to use and override it. I've never tried this so I don't know how practical this might be.
3) Make the style sheet definition in your jsp pages an OGNL expression and provide that information in a base action class that all your actions extend. In this way you end up with (potentially) a different CSS file for each client and you provide your customisation via CSS.
Hope that this helps.
Is anyone aware of a stateless tree component in Apache Wicket that works similarly to the JTree/TreeModel concept in Swing? I'm specifically looking for a static tree, i.e. no fancy AJAX or the like — just a plain and simple way of displaying a tree model.
You say you want a static, AJAX-less tree... does it even have to be a formal tree component? If not, you might be able to use recursive panels to mimic a tree, as illustrated here in the Wicket Examples (source code). It really depends on your use case, though.
I was also going to suggest going ahead and using one of the fancy trees, like this one, and overriding the behavior of clicking on the tree to "do nothing." Unfortunately, it looks like the expand/collapse methods are built in at such a deep level that that's not possible. There is no built-in class that does exactly what you want.
I'm working on a utility that will be used to test the project I'm currently working on. What the utility will do is allow user to provide various inputs and it will sends out requests and provide the response as output.
However, at this point the exact format (which input is required and what is optional) has yet to be fleshed out. In addition, coding in Swing is somewhat repetitive since the overall work is simple though this should be the safest route to go as I have more or less full control and every component can be tweaked as I want. I'm considering using a configuration file that's in XML to describe the GUI (at least one part of it) and then coding the event handling part (in addition to validation, etc). The GUI itself shouldn't be too complicated. For each type of request to make there's a tab for the request and within each tab are various inputs.
There seems to be quite a few questions about this already but I'm not asking for a 3rd party library to do this. I'm looking to do this myself, since I don't think it'll be too overly complicated (hopefully). My main consideration for using this is re-usability (later on, for other projects) and for simplifying the GUI work. My question is: are there other pros/cons that I'm overlooking? Is it worth the (unknown) time to do this?
I've built GUI in VB.NET and with Flex3 before.
XML is so 2000. It's code, put it in real source files. If it really is so simple that it could be XML, all you are doing is removing the XML handling step and using a clearer syntax. If it turns out to be a little more complicated than you first expected, then you have the full power of your favourite programming language to hand.
In my experience, if your layout really is simple, something like the non-visual builders in FormLayout can lead to really concise code with a minimum of repetition.
If you have to specify the precise location of every control you might look at a declarative swing helper toolkit that can minimize boilerplate and simplify layout. Groovy supports this as does JavaFX, and both are simple library extensions to Java (give or take).
If the form is laid out in a pattern, using a definition file in a format like XML or YAML will work. I've done that and have even set up data bindings in that file so that you don't even have to deal with listeners or initial values...
If you are sure you want XML, I'd seriously consider YAML though, it's really close but instead of:
<outer>
<inner a=1> abc </inner>
</outer>
I think it's a lot more like:
outer
inner a=1
abc
(I may have that a bit wrong, but that's close I think. Anyway, you should never force anyone to type XML--if you are set on XML, provide a GUI with which to edit it!)