We Keep Coding

Custom xwiki renderer

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

inner working of JSF 1.2

I'm trying to understand the inner workings of JSF 1.2 sun implementation.
I have the following questions.
It is stated that Lifecycle class manages the processing of the entire lifecycle of a particular JavaServer Faces request. It has execute and render methods but its a abstract class. How is it really implemented?
In this blog, he states that the ViewHandler will eventually call the following:
stateManager.saveView(context);
Is this correct? I couldn't find anywhere this line of code.
In which class would I find the code that parses the JSF tags and created component tree, (xml -> tree)?
In which class would I find the code that does the reverse of (3) i.e. renders the component tree. (tree -> xml)?
It would also be infinitely great if someone could point me to any resource that provides explanation about JSF 1.2 implementation.

It's been a few years since I've been in the guts of JSF 1.2, but if memory serves the class implementing Lifecycle was always LifecycleImpl.
Regarding the conversion between xml->tree and tree->xhtml (for me, anyways), I always thought that was done by the Components / Renderers / Converters. Based on a tag, a Component is created and populated in the tree. The Renderer attached to the Component (based in the tag definition) is responsible for rendering the output (by default html, but you can have multiple renderers attached to a component based on the desired output), and the Converter is responsible for the String <-> Object conversions.
I always had good luck reading the source (can be found at http://javaserverfaces.java.net/download.html), although it took a few tries to get my head around some of it.
Hope this helps

Can tiles have action classes?

In Stuts2 I am using Tiles plugin to create a layout for the website (menu, footer, header etc.) that is consistent on every page.
Now each tile is just a static HTML content.
Is it possible to make a Tile more dynamic by eg. calling a Footer action class every time the footer is to be rendered? For example: to fetch footer content from database.
If I was to do that inside every page's action class in my application this would make for a very unusable code...
So maybe it is possible from Tile perspective?

There is only one way to do what you ask with a tiles version less than 2.2.2 and that is with a "preparer".
This however is not an integration with struts2 but would mean the preparer it self will access the service layer to get the required content for the view and all that content would need to be set though tiles attributes.
With tiles versions 2.2.2 and higher:
You can use OGNL expressions within tiles attributes, this can allow access to some struts2 interaction as well as static method access. With static method access you can call a method to return a string how ever you want. Creating such a string would be on par with writing a scriptlet.
To upgrade you need to either manually override some jars to get tiles 2.2.2, or to get version three you will need to implement your own result type: How to integrate Struts 2 with Tiles 3.
I don't actually recommend either of the above methods at this time, tiles 3 is recommended but not as an excuse to do something as bad as writing a scriptlet. It would probably be better to use the s:action tag in a tile, as mentioned by David or use an Ajax method as mentioned by Jaiwo99. The reason being that both these methods keep with struts2 while the ones I presented would be unusual and be harder to maintain. Personally I would lean towards the ajax methods.
Struts2 along with the struts2-json-plugin makes creating json services very simple. Tiles is a nice system for reducing boiler plate. If ajax is used heavily the two really can compliment each other. You can make a lot of reusable ajax components, just be sure to not hard code the urls of actions. Always use the s:url tag and assign that to JS variables.

Try following code:
$('#footer').load('your/action/with/namespace');
i'm assuming your footer is with id footer, everytime you open a page, your footer action class will be called and the data can be fetched dynamically.

How to get the DOM of a JSF 2.0 component's generated HTML from the backing bean?

I have a JSF-page containing only a PrimeFaces Calendar component, backed by a view scoped bean.
<p:calendar value="#{calendarBean.today}" mode="inline" showOtherMonths="true" pages="1" binding="#{calendarBean.model}" />
The generated HTML for this component contains a table that I'd like to adjust. More specifically, I want to put icons dynamically into this calendar by adding some HTML-code under the td-tags of the targeted days.
From the CalendarBean I can fetch from some service a list of objects representing days "with icons". I need this list to decide which days to alter in the table. I tried to get the HTML DOM in my backing bean, but I don't understand how. The UIComponent tree (that I get via the binding property) only contains the JSF-components, not the generated HTML. I start to doubt if this is even the way to approach the problem.
My google-skills seem to fall short here. Can anybody help me?

The concrete functional requirement is not entirely clear, so it's hard to propose the right way for this, but there are in general varous ways to alter the look'n'feel of the JSF/PrimeFaces-generated HTML.
Use custom CSS. Icons could simply be set as CSS background images.
Use custom JS. JS has instant access to the entire HTML DOM tree.
Use custom JSF renderer. Extend the PrimeFaces CalendarRenderer class and override the encodeXxx() method(s) accordingly.
The backing bean is supposed to be the controller between the view (the XHTML file) and the model (the javabean entity class holding the data which is to be presented to the enduser or to capture the submitted data from enduser). It isn't supposed to manipulate the HTML.

IlleagalStateException when wrapping spring mvc select tag with custom tag

Basic problem
I've come across a bit of a problem while writing my own custom JSP tags to "wrap" the spring MVC form tags. I've wrapped other tags successfully but come unstuck with the select and options tags, this throws an IlleagalStateException. I've debugged the spring code and found that the options tag looks for an ancestor select tag. I'm doing this with tag files so the spring select tag is actually in a different tag file. I guess that's why it doesn't find it.
So the questions is what can I do to get round this?
Possible solutions
I've tried looking for solutions but all I've found is other people having the same problem but no solution posted. I did ponder writing my own select and options tags without using the spring tags but I don't really want to have to replicate the binding that it gives you for free. I don't mind changing to use Java classes rather than tag files but I found previously that the output won't be evaluated as a JSP so you can't output another JSP tag.
Reasons for doing this
Having thought about this for a week since first asking the question I am now clearer on what I want to achieve.
To simplify the markup needed in my JSP's
Factoring out common code (e.g. form:errors after an input or getting a translation from spring:message)
To encapsulate look and feel (CSS goes a long way but often you need to change the markup too)
To be able to build enhanced components that extend the functionallity of the spring tags (e.g. render a multi-select as a picklist or display readonly inputs as text labels)
I'll be interested to hear what people think.
Thanks

Firstly, I'm not sure what you mean by wanting control over styling. I thought you could pass-in class and id attributes to Spring tags and they were copied through (? - although I might be getting confused with Grail tags, as I've been writing Grails apps lately). Edit: plus you can style Spring generated tags by referencing an outer element. E.g. surround your form elements with a div and then style the form elements like: #myDiv input { color: red; }.
From my experience (10+ years webapp dev), its not worth the extra effort to try and future proof your app. When you choose a framework like Spring MVC you are getting a lot of stuff for free, that you would normally have to write yourself. The cost of this free stuff is a certain amount of lock-in (as you said). Spring is pretty good when it comes to this aspect - you can use as little or as much as you want and its usually pretty straight forward to engineer it out if needs be in the future.
So my take is: use the Spring tags "as is". The likelihood of you needing to remove the Spring aspect in the future is very small. As such its a worthwhile risk to "put off" if/until that scenario arrises. You have likely already spent as much time and code trying to engineer your future-proof solution as you would've spent removing the Spring tags - that it outweighs any benefit it might have provided. And add to that - you've written that code and you and/or someone else will have to maintain that code now - versus letting the Spring developers maintain the code for you.
Lastly, if you really don't want to have this lock-in and want full control over styling, then write your form elements by hand.
<select name="foo_select">
<option value="">-- select a foo type --</option>
<c:forEach var="foo" items="${fooGroups}">
<option value="${foo}">${foo}</option>
</c:forEach>
</select>

I've thought about this for a good week now and this is the shortlist:
Give up and directly use the spring tags in my JSP's
Don't use the spring tags at all and replicate their logic in my own tags
Possibly write a tag class that extends or makes use of the spring tag class
Expand the scope of my tags to wrap both the select and options tags
Given the reasons for wanting to do this (which I have now clarified in the question), I've decided to go for the last option. I wasn't keen on this originally because I thought I might end up with hundreds of parameters but it's actually not too bad. The tag files are designed for wrapping common bits of markup so this is what they're for. I've also wrapped my own tag further so there is a picklist tag which outputs my custom select tag and then writes the JS needed to initialise it.
I think this is the best of the possible solutions I've come across based on what I wanted to achieve. This is what I'm going with but I'd still be interested to hear of other peoples solutions if they think they have something better.