Article: JSFTemplate Components

Discussions

News: Article: JSFTemplate Components

  1. Article: JSFTemplate Components (27 messages)

    Ken Paulsen has documented his newspaper-style component as an example of JSFTemplating, a library on java.net that provides a template language for use in JSF rendering. Making the creation of components easier is one of the goals of the JSF 2.0 JSR, of which Ken's a member; it's worth keeping your eye on the templating technologies.
    In this article I'd like to propose an approach to simplify the Renderer portion of [the JSF component creation] problem. This isn't a cure for all the problems of creating a component, but it is a step in the right direction. It may not even be the ideal solution for Renderers, but it’s much better than alternatives available today. The approach is to create a template-based Renderer to declaratively define the output of the component. This approach is implemented in the JSFTemplating project. In fact, the project's initial goal was solely to simplify JSF Renderer creation; however, the focus has moved to page creation lately.

    Threaded Messages (27)

  2. I remember looking at this project at an early stage. Why Ken was very helpful, I had to stop using JSFTemplate because of the lack of documentation. I hope that some effort has been put into documenting this project, because it is heading in the right direction. --Todd
  3. Re: Article: JSFTemplate Components[ Go to top ]

    I remember looking at this project at an early stage. Why Ken was very helpful, I had to stop using JSFTemplate because of the lack of documentation.

    I hope that some effort has been put into documenting this project, because it is heading in the right direction.

    --Todd
    Mhh I am not sure if this is the correct approach. After all a JSF component normally has the Tag Code which does the binding into JSP, the component code itself which should be the controller part and the renderer which is purely the view part. Now we have the component, a handler and a view, the handler seems to be an annotation grave. While I applaud that the component itself automates the tedious save restore and setter getter mechanisms, I cannot see the full advantage here. The number of artifacts is not really reduced, and it still seems somewhat too hard. I personally would love to see a different approach of having one component and one template and a set of tools classes pushed as helpers into the template (sort of the approach Turbine does on high level with velocity) As for the JSP bindings->annotations if possible. So in the end the result should be ->component = controller Template = view nothing else if possible.
  4. Re: Article: JSFTemplate Components[ Go to top ]

    I personally would love to see a different approach of having one component and one template and a set of tools classes pushed as helpers into the template...
    Watch Jason Lee's blog for a post that comes much closer to your vision. My article was strictly focused on simplifying a JSF Renderer, I agree more must be done to simplify JSF component development as a whole. I think JSFTemplating provides a good solution for a component "Template", in fact if you prefer a different syntax (such as Facelets) it offers that too. Jason will demonstrate how to simplify the rest of the component development using some annotations to generate the JSP tag handler, and other required plumbing. Watch this blog for an entry w/i the next day or two: http://blogs.steeplesoft.com/ Ken
  5. Re: Article: JSFTemplate Components[ Go to top ]

    I think JSFTemplating provides a good solution for a component "Template", in fact if you prefer a different syntax (such as Facelets) it offers that too.

    Ken
    I want to be careful on syntax vs. features when you compare Facelets to JSFT. Yes, you could use Facelets' XML approach to conventional XML syntax (@see JSPX), but that's where it stops. I'd honestly rather seen JSFT expand/enhance Facelets' model, but that's left for more of a private discussion ;-)
  6. Re: Article: JSFTemplate Components[ Go to top ]

    I want to be careful on syntax vs. features when you compare Facelets to JSFT. Yes, you could use Facelets' XML approach to conventional XML syntax (@see JSPX), but that's where it stops.
    Which is all Ken wants, at the moment, as far as I know. The goal is to provide a format people like, not replace or reproduce Facelets itself...
  7. JSFTemplating & Facelets[ Go to top ]

    I'd honestly rather seen JSFT expand/enhance Facelets' model, but that's left for more of a private discussion It's a pity that JSFTemplating is introducing another codebase where there already exists a templating solution that pioneered these things and has a sizeable adoption from the JSF community: Facelets.
  8. Re: JSFTemplating & Facelets[ Go to top ]

    I'd honestly rather seen JSFT expand/enhance Facelets' model, but that's left for more of a private discussion

    It's a pity that JSFTemplating is introducing another codebase where there already exists a templating solution that pioneered these things and has a sizeable adoption from the JSF community: Facelets.
    You'll be happy to know that what you describe is exactly the kind of thing for which JCP was created. You will also be happy to know that the JSF 2.0 expert group is using this feature of the JCP. Ed - JSF 2.0 co-spec-lead
  9. Re: JSFTemplating & Facelets[ Go to top ]

    I'd honestly rather seen JSFT expand/enhance Facelets' model, but that's left for more of a private discussion

    It's a pity that JSFTemplating is introducing another codebase where there already exists a templating solution that pioneered these things and has a sizeable adoption from the JSF community: Facelets.


    You'll be happy to know that what you describe is exactly the kind of thing for which JCP was created. You will also be happy to know that the JSF 2.0 expert group is using this feature of the JCP.

    Ed - JSF 2.0 co-spec-lead
    FYI, JSFTemplating was created before Facelets was public, although it became public itself after Facelets. Facelets has a great syntax and introduced some great concepts -- I recognize that. As Ed pointed out the JCP process will help bring standardization in this area.. however, before a standard is set, it is healthy for more than 1 project to experiement in this area. Due to JSFTemplatings modular syntax design, JSFT has been able to support most of the Facelets syntax in addition to its 2 other syntaxes -- so feel free to use the Facelets syntax (w/ ui:composition's, ui:define, ui:includes, etc.) to write JSFTemplating components. I look forward to JSR 314 bringing some standardization in this area and am helping in that processes (as is Jacob). Ken Paulsen
  10. Re: Article: JSFTemplate Components[ Go to top ]

    I personally would love to see a different approach of having one component and one template and a set of tools classes pushed as helpers into the template (sort of the approach Turbine does on high level with velocity)
    As for the JSP bindings->annotations if possible.

    So in the end the result should be ->component = controller
    Template = view nothing else if possible.
    Take a look at one of my JavaOne presentations on "Simplifying Component Development": http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-6178&yr=2007&track=8. The "intuition" example at the end does just that. Of course, I never released it as a separate project :-(. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  11. I do appreciate that any technology follows an evolutionary path, but whenever I look into JSF I find a whole stream of libraries and 'add-ons' with the goal of 'Simplifying' JSF. My gut reaction is that a technology (especially one that is relatively recent, like JSF) that requires so many 'simplifications' is rotten at the core. I did spend a short while trying to learn JSF, so I can understand why the simplification is required. A couple of hours of chowing down on 'JSP Tag Soup' was enough for me to put the book down and to find something else. Fortunately, I came across Wicket and never looked back. I have a distinct impression that JSF is another 'EJB 1'. We will have a couple of revisions that will slightly improve the situation (as well as introduce a whole new class of problems) and eventually some leading guru on a similar open source project will voluteer to get involved. The spec will be dramatically altered and we will have something workable. I have paid my debt with EJB 1.1, 2.0 and 2.1. I will let you guys hack away at JSF.... just let me know when you are done :).
  12. Re: Article: JSFTemplate Components[ Go to top ]

    I do appreciate that any technology follows an evolutionary path, but whenever I look into JSF I find a whole stream of libraries and 'add-ons' with the goal of 'Simplifying' JSF. My gut reaction is that a technology (especially one that is relatively recent, like JSF) that requires so many 'simplifications' is rotten at the core.

    I did spend a short while trying to learn JSF, so I can understand why the simplification is required. A couple of hours of chowing down on 'JSP Tag Soup' was enough for me to put the book down and to find something else. Fortunately, I came across Wicket and never looked back.

    I have a distinct impression that JSF is another 'EJB 1'. We will have a couple of revisions that will slightly improve the situation (as well as introduce a whole new class of problems) and eventually some leading guru on a similar open source project will voluteer to get involved. The spec will be dramatically altered and we will have something workable.

    I have paid my debt with EJB 1.1, 2.0 and 2.1. I will let you guys hack away at JSF.... just let me know when you are done :).
    Actually the situation is not as bad as you describe it but jsf has some areas which really need improvement. The component model is the one which probably is in the most serious need for an overhaul. But overall JSF is a pretty good framework, but like every framework it has some weak points. I dont think it is comparable to EJB1, JSF is sort of EJB 2.5 in its current 1.2 incarnation (which means somewhere between EJB2 and EJB3 in usability) which means most areas work pretty well by now, but some still need improvement. I personally think that most frameworks need at least three incarnations until most issues are addressed and JSF seems to be the rule not the exception here. (Although JSF 1.2 only has few issues left which are not addressed)
  13. Re: Article: JSFTemplate Components[ Go to top ]

    Actually the situation is not as bad as you describe it
    Ok. I am certainly willing to entertain that possibility. It has been a little while since I looked at JSF, so I am sure things have moved forward. I originally came to look at JSF after using Tapestry(3) for a while and at the time, JSF seemed like a bit of a step backwards. Tapestry was reasonably complicated to use, but JSF seemed more so. I do remember there being a few things that gave me one of those, "Well, thats pretty cool!" moments, but a few more that provided the, "Why, Oh Why?" feeling. I think the final straw for me was the 'verbatim' tag. It left me with a feeling of, "Hang on, what exactly am I writing here? A component tree or a web page?". Not to hijack the conversation, but I think it would take quite a lot to pull me away from Wicket now. I have decided that Wicket was exactly what I was looking for when I moved away from Tapestry. I like the way the Wicket core classes really model a web application. It's great to have classes like 'WebPage' and 'WebSession'. It seems to be a solution that fits the problem nicely and I have discovered, through hard won experience, that when the code models the problem, the design usually scales nicely, new features usually have a 'natural home' inside the model. Also the fact that the templates are pure html (to the point that they are 'previewable' inside the browser) is a big plus for me also. When I last looked at JSF, the view tech was JSPs with nested custom tags (still the case right?), so this was not possible. I understand that different teams have different priorities, and JSF may work very well for them. JSF does have the 'official Sun stamp' going for it, and I am sure this is a big pull. It would have had a big effect on me 5 years ago too, but I have spent the time since realizing that it is the independantly developed open source frameworks that are really innovating (Hibernate, Spring, Wicket). So, something being J(2)EE core carries less weight with me today. That said, my next contract may possibility be with a client that has already decided to stick with Sun sanctioned technologies and if so I may have to dip my toe into JSF waters again. Maybe, if I am forced into that position, I will find JSF will win me over, but for now (and with far too many web frameworks available as it is), I find it difficult to justify heading back that way.
  14. Re: Article: JSFTemplate Components[ Go to top ]

    Actually the situation is not as bad as you describe it


    Ok. I am certainly willing to entertain that possibility. It has been a little while since I looked at JSF, so I am sure things have moved forward.

    I originally came to look at JSF after using Tapestry(3) for a while and at the time, JSF seemed like a bit of a step backwards. Tapestry was reasonably complicated to use, but JSF seemed more so. I do remember there being a few things that gave me one of those, "Well, thats pretty cool!" moments, but a few more that provided the, "Why, Oh Why?" feeling. I think the final straw for me was the 'verbatim' tag. It left me with a feeling of, "Hang on, what exactly am I writing here? A component tree or a web page?".

    Not to hijack the conversation, but I think it would take quite a lot to pull me away from Wicket now. I have decided that Wicket was exactly what I was looking for when I moved away from Tapestry. I like the way the Wicket core classes really model a web application. It's great to have classes like 'WebPage' and 'WebSession'. It seems to be a solution that fits the problem nicely and I have discovered, through hard won experience, that when the code models the problem, the design usually scales nicely, new features usually have a 'natural home' inside the model.

    Also the fact that the templates are pure html (to the point that they are 'previewable' inside the browser) is a big plus for me also. When I last looked at JSF, the view tech was JSPs with nested custom tags (still the case right?),
    Yes, but since JSF 1.2 it is possible to mix and match jstl, jsf and jsp without the interferences JSF 1.1 had, but nowadays most developers utilizing jsf simply prefer facelets (which you might love if you come from the tapestry side) Facelets kicks jsf altogether. so this was not possible.

    I understand that different teams have different priorities, and JSF may work very well for them. JSF does have the 'official Sun stamp' going for it, and I am sure this is a big pull. It would have had a big effect on me 5 years ago too, but I have spent the time since realizing that it is the independantly developed open source frameworks that are really innovating (Hibernate, Spring, Wicket). So, something being J(2)EE core carries less weight with me today.

    That said, my next contract may possibility be with a client that has already decided to stick with Sun sanctioned technologies and if so I may have to dip my toe into JSF waters again. Maybe, if I am forced into that position, I will find JSF will win me over, but for now (and with far too many web frameworks available as it is), I find it difficult to justify heading back that way. Good luck, I personally think there doesnt have to be an uber framework, there is lots of room and lots of frameworks fill certain nieches. I personally like JSF for what it is, and try to utilize it as often as possible, but I can also see its downsides.
  15. Re: Article: JSFTemplate Components[ Go to top ]

    I think the final straw for me was the 'verbatim' tag.
    verbatim tag issue is solved since jsf 1.2. Also 1.1 solves the issue if you use Facelets as view technology. Probably you tried the framework quite some ago, or you didn't give en enough attention to the jsf world.
    When I last looked at JSF, the view tech was JSPs with nested custom tags (still the case right?), so this was not possible.
    No, this is absolutely possible if you use Facelets instead of JSP. IMHO almost 90% of JSF developers is using this extension. As final note, I want to say "let you try jsf again". Latest release (JSF 1.2) is a big step forward repect to previous one. I had issue with that tag-soup with JSP + Myfaces 1.1, but then went out this version and I discovered Facelets. Now my pages are very concise, and I am not experimenting any JSF bugs (myfaces 1.1 was plenty of them).
  16. I do appreciate that any technology follows an evolutionary path, but whenever I look into JSF I find a whole stream of libraries and 'add-ons' with the goal of 'Simplifying' JSF. My gut reaction is that a technology (especially one that is relatively recent, like JSF) that requires so many 'simplifications' is rotten at the core.
    Couldn't agree more. They made every thing a joke. Some time I am amaze who is running the show in Java world and do they have any common sense or not. They took JSP and made it notoriously complex and guess what we have got after 4 years; competing templates, tag libraries tons of deployment descriptors and no body knows from where to start and grasp the JSF. The guys who are running the show even couldn't learn it from MS, who elegantly implemented Web Forms years ago; and guess what the average VB developer is using Web Forms every where with out any sweat VS experience server side Java developers, who are throwing their books after reading the first few chapter of their JSF books. Shame on JSF team and shame on Java community who loose all their common sense try to make things simpler; my request; please spare us; no more frameworks to make our life easier; we can still code web applications with the regular Java stack more faster than JSF.
  17. I do appreciate that any technology follows an evolutionary path, but whenever I look into JSF I find a whole stream of libraries and 'add-ons' with the goal of 'Simplifying' JSF. My gut reaction is that a technology (especially one that is relatively recent, like JSF) that requires so many 'simplifications' is rotten at the core.


    Couldn't agree more. They made every thing a joke. Some time I am amaze who is running the show in Java world and do they have any common sense or not. They took JSP and made it notoriously complex and guess what we have got after 4 years; competing templates, tag libraries tons of deployment descriptors and no body knows from where to start and grasp the JSF. The guys who are running the show even couldn't learn it from MS, who elegantly implemented Web Forms years ago; and guess what the average VB developer is using Web Forms every where with out any sweat VS experience server side Java developers, who are throwing their books after reading the first few chapter of their JSF books. Shame on JSF team and shame on Java community who loose all their common sense try to make things simpler; my request; please spare us; no more frameworks to make our life easier; we can still code web applications with the regular Java stack more faster than JSF.
    I can't necessarily argue with you. JSF was originally designed to cater to tool-based development in order to increase Java adoption for web development via higher levels of abstraction. For skilled developers, the abstraction can get in the way and presents itself as unecessary complexity, especially for those who can do HTML, JavaScript, JSON, Servlets, XML, state management, parameters, etc without batting an eye. For others, the JSF route clicks completely at the level of handholding their looking for in writing their apps. JSF has increasingly grown in popularity but I can see how those, who have the desire and the capability to do everything themselves can see JSF as an unwanted addition.
  18. They made every thing a joke. Some time I am amaze who is running the show in Java world and do they have any common sense or not. They took JSP and made it notoriously complex and guess what we have got after 4 years; competing templates, tag libraries tons of deployment descriptors and no body knows from where to start and grasp the JSF. The guys who are running the show even couldn't learn it from MS, who elegantly implemented Web Forms years ago; and guess what the average VB developer is using Web Forms every where with out any sweat VS experience server side Java developers, who are throwing their books after reading the first few chapter of their JSF books. Shame on JSF team and shame on Java community who loose all their common sense try to make things simpler;
    Shame on who spreaks without knowing the object of his speaking. It's quite obvious you are refering to older version of JSF, or you didn't spend much time trying to understand JSF, or worse trying to document on how a JSF project should be done. I invite you to review your opinions giving a second glance to JSF 1.2 in conjunction with Facelets. Or, if you already know these framework, try to argue better you complaints.
  19. Re: Article: JSFTemplate Components[ Go to top ]

    They made every thing a joke. Some time I am amaze who is running the show in Java world and do they have any common sense or not. They took JSP and made it notoriously complex and guess what we have got after 4 years; competing templates, tag libraries tons of deployment descriptors and no body knows from where to start and grasp the JSF. The guys who are running the show even couldn't learn it from MS, who elegantly implemented Web Forms years ago; and guess what the average VB developer is using Web Forms every where with out any sweat VS experience server side Java developers, who are throwing their books after reading the first few chapter of their JSF books. Shame on JSF team and shame on Java community who loose all their common sense try to make things simpler;


    Shame on who spreaks without knowing the object of his speaking.
    It's quite obvious you are refering to older version of JSF, or you didn't spend much time trying to understand JSF, or worse trying to document on how a JSF project should be done.

    I invite you to review your opinions giving a second glance to JSF 1.2 in conjunction with Facelets.

    Or, if you already know these framework, try to argue better you complaints.
    Actually the funny thing is that he mentioned web forms, which is very similar to JSF, WebForms mainly has the advantage of pushing one single IDE, while we have the visual webpack most people code JSF by hand. People who use WebForms simply draw the stuff with VStudio, once you go down from the visual tools WebForms can become really ugly ;-), the IDE just hides it. It probably is better to compare WebForms with the Netbeans Visual Webpack in this regard.
  20. They made every thing a joke. Some time I am amaze who is running the show in Java world and do they have any common sense or not. They took JSP and made it notoriously complex and guess what we have got after 4 years; competing templates, tag libraries tons of deployment descriptors and no body knows from where to start and grasp the JSF. The guys who are running the show even couldn't learn it from MS, who elegantly implemented Web Forms years ago; and guess what the average VB developer is using Web Forms every where with out any sweat VS experience server side Java developers, who are throwing their books after reading the first few chapter of their JSF books. Shame on JSF team and shame on Java community who loose all their common sense try to make things simpler;


    Shame on who spreaks without knowing the object of his speaking.
    It's quite obvious you are refering to older version of JSF, or you didn't spend much time trying to understand JSF, or worse trying to document on how a JSF project should be done.

    I invite you to review your opinions giving a second glance to JSF 1.2 in conjunction with Facelets.

    Or, if you already know these framework, try to argue better you complaints.
    No my friend I won't going to look into JSF 1.2; I will wait for version 5.0 or later :-); when JSF team will really learn what it means to deliver a server side control for webs. And yes just to let you know the object of my speaking is not JSF 1.2; neither it is JSF 1.X and future version of 5.0:-)that is how intelligent people like you speak; rest of us speak with common sense. Go brush up your knowledge about the server side web controls beyond Java and then come back and talk to me; you won't be disappointed:-) Leave in peace and have fun with JSF 1.2.
  21. No my friend I won't going to look into JSF 1.2; I will wait for version 5.0 or later :-); when JSF team will really learn what it means to deliver a server side control for webs. And yes just to let you know the object of my speaking is not JSF 1.2; neither it is JSF 1.X and future version of 5.0:-)that is how intelligent people like you speak; rest of us speak with common sense.
    Ok, you don't know almost anything of newest JSF but you can argue that its team should learn what it mean to deliver server side control for webs. Maybe common sense is 6th sense? Instead on going on with these no-argumentations, explain to us why JSF is so horrible, if you can (but I doubt).
  22. No my friend I won't going to look into JSF 1.2; I will wait for version 5.0 or later :-); when JSF team will really learn what it means to deliver a server side control for webs. And yes just to let you know the object of my speaking is not JSF 1.2; neither it is JSF 1.X and future version of 5.0:-)that is how intelligent people like you speak; rest of us speak with common sense.


    Ok, you don't know almost anything of newest JSF but you can argue that its team should learn what it mean to deliver server side control for webs.
    Maybe common sense is 6th sense?

    Instead on going on with these no-argumentations, explain to us why JSF is so horrible, if you can (but I doubt).
    Hoin... I had some concerns about the JSF since it's inception and I even argued some of your masters who taught the great JSF 1.2 too you: Enjoy and see out side the box (JSF 1.2) http://www.theserverside.com/news/thread.tss?thread_id=19680#85327
  23. I have proffesional experience in JSF and eventually made a template in plain java code, that worked out well. It was tricky to set up though because the API is very verbose and tedious. JSF needs to be simplified. The concept is OK but the specmakers should look at other frameworks how things could get easy.
  24. I have proffesional experience in JSF and eventually made a template in plain java code, that worked out well. It was tricky to set up though because the API is very verbose and tedious. JSF needs to be simplified. The concept is OK but the specmakers should look at other frameworks how things could get easy.
    We on the Expert Group are doing that very thing.
  25. I have proffesional experience in JSF and eventually made a template in plain java code, that worked out well. It was tricky to set up though because the API is very verbose and tedious. JSF needs to be simplified. The concept is OK but the specmakers should look at other frameworks how things could get easy.

    We on the Expert Group are doing that very thing.
    that is good news ;)
  26. Tried Seam?[ Go to top ]

    I started developing an application using JSF on JSPs and EJBs directly and the complexity of developing began to dig in. However when i switched to Seam, i began to love JSF more and appreciate where JSF's power really lies: component driven web apps. I think Seam already solves a lot of the problems with JSF and a lot of lessons can be learnt from it. Ditto Facelets
  27. Re: Tried Seam?[ Go to top ]

    I started developing an application using JSF on JSPs and EJBs directly and the complexity of developing began to dig in. However when i switched to Seam, i began to love JSF more and appreciate where JSF's power really lies: component driven web apps.

    I think Seam already solves a lot of the problems with JSF and a lot of lessons can be learnt from it. Ditto Facelets
    Actually I personally think Seam solves less problems within the JSF real (it does solve some though) but more along the lines of complexity of general webapp development in conjunction with orm. Most problems you face in a webapp are very similar and it does not matter which frontend framework you utilize. Seam does solve some JSF problems in the realm of master detail bindings, and data table. But I think people experience the biggest boost on simplification simply by the fact that they are finally again in a stateful context regarding their backend controller and db access logic. Seam more or less pushes the programming model of rich client interfaces into web centric contexts. So if you want to give Seam the credits then basically more along those lines :-)
  28. Layout Components[ Go to top ]

    To me this thread has taken a strange direction and I think it has to do with the unfortunate use of the word Template. Template to most invokes XML and the subsequent discussions about Facelets and Tapestry. I read the article and found it confusing. So let me convey what I think this is all about. Creating layout components is not new in JSF. Almost every third party offering has some layout capability especially when it comes to providing tabs. One of the best components offerings in providing UI layout widgets is Oracles ADF and Apache Trinidad. This is not templating and the example provided in the article is NOT templating, is is component layout. To me a UI template is content driven and the template directs the content to appropriate regions in a display. I don't think it serves much purpose to mix the two concepts. UIs today are commonly expressed two ways, programatically or declaratively. To me programatically is like Swing (JSF does support this form) in which you use both layout and widget type components to construct (code) the UI. Declarative is more like XML where you describe the UI layout structure and it then gets compiled (JSP) or interpreted (Faclets). Once you put all of these includes and conditional logic, whose sole purpose is to manage content, in the declarative XML you end up with a mess and you have not gotten far beyond JSP. Personally a template language is a transformative one and if you using XML as your declarative language then your transformation engine should be using XSLT. My personal feeling is that if you cannot write a JSF view without using ONLY JSF components then you don't have the right set of components. IF you are writing JSF and being forced to sprinkle in HTML then I do not think JSF is serving you well. Practical JSF (which is not the standard) needs a richer set of both Widget and Layout Components. We are getting there and providing better tools and mechanisms to write components would help some. JSF 2.0 should start by defining a core set of advanced widgets and layout components and let the market provide the renderkits.