Re: [Rife-users] Re: implementing a RIFE view component
How about you, Geert? Which frameworks have you tried and what were your impressions? Also, which frameworks were you working with before you decided to create RIFE? What prompted you to embark on this endeavor? I started working on RIFE more than 5 years ago. At that point in time there wasn't really much out there. I know that during the development, Tapestry was announced and I saw a lot of the others come and go along the years. I still remember Spring being announced and me feeling very depressed about it, until I realized the focus was totally different ;-) This version of RIFE is actually the third take on the matter. Beforehand I learned a lot about what was needed in a web framework by having written a full-stack one in PHP as a consultant for a company. We wrote some big sites with it (~60k loc), which made me see its shortcomings. In 1998 I moved on as a full-time employee to a company that mainly did Java, which is where I learned the language (still at version 1.0 or 1.1 then). I began writing a new framework for them, in Java, where I mostly designed the templating approach and the database layer. At that time it even went further and contained a somewhat functional in-memory database for standalone apps. I left there at the end of 1999 and started doing independent contracting again. Since I couldn't use any of the framework code I wrote due to licensing issues, I decided to rewrite it once more from scratch, this time really taking the time to design the web engine in a componentized fashion with flow handling. That when the current version of the framework was born, initially called Matchbox and then renamed RIFE. Recently I've been looking quite a bit at Wicket and like many of the things I see there. I've played around with WebWork also. Besides that I haven't really tried out much since it's already hard to find the time required to work on RIFE. I do try to keep my eyes open for important new things that arrive. If others have experiences, thoughts and reactions about trying out different frameworks, it would be interesting to read about them. Yes, definitely, that would be most interesting to read about! -- Geert Bevin Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Re: Please help testing RIFE 1.5M2
I'll try out the stateful view components. Frederic ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Re: implementing a RIFE view component
> We'll definitely have to get some drinks together if we ever meet That would be cool! How about you, Geert? Which frameworks have you tried and what were your impressions? Also, which frameworks were you working with before you decided to create RIFE? What prompted you to embark on this endeavor? If others have experiences, thoughts and reactions about trying out different frameworks, it would be interesting to read about them. Frederic ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
OK one last thing, Geert is an awesome person and the RIFE community is extremely responsive and helpful. Not to be taken for granted! *blush* We'll definitely have to get some drinks together if we ever meet :-) Hope this helps. Feel free to ask for any more precisions concerning the frameworks I mentioned. -- Geert Bevin Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
I don't understand why they would even ask for an example; it is not that hard adding state to an embedded element. Anyway, the truth is, although components What they were talking about is not to add external state to an embedded element by for example injecting spring beans or so into it, but by having the elements maintain their own view state without any additional work. That isn't possible in RIFE before version 1.5. are possible with RIFE, there is still a lot of work to be done to make it easy for developers to create generic components. The ordered processing of embedded elements is a good move towards that, but other features will be necessary. I am sure you are already aware of those. I'd be interested in hearing about the features you still consider necessary to have generic components. Of course, they will always have to be designed for genericity in that you can only parametrize what has been setup for customization. is like a cow's opinion - it doesn't matter. :-) Ow. Wicket has got quite some nice ideas and approaches. I think that RIFE can still steal some things from them (though not much) ;-) Exactly what I wrote in my last post: Wicket is well thought of and should be kept on the radar. I think that Wicket's ease of use, configuration reduction and developer friendliness is something to keep our eyes on. Luckily these have always also been a focus of RIFE, though in a different direction. It's nice though to see that Wicket is also borrowing ideas from us though :-) -- Geert Bevin Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Re: implementing a RIFE view component
> I'd be very interested to get your view on why you prefer to stick > with RIFE after having tried out all these others. Particularly in > the light of some comparison evaluations that will be performed by a > large company next week. FWIW, I've also tried Tapestry, Wicket, WebWork, JSF, Stripes, Echo2, SpringMVC and Millstone. Here are some thoughts; I'll try to keep this brief, feel free to ask for more information on any specific topic. After RIFE, my favorites are WebWork, Tapestry and Stripes. I did not like working with the others. I dropped Echo2 and Millstone because I found they were doing too much for you in terms of rendering. Nice ideas, but I still like to have control over the HTML. Also, it's too much API to learn. SpringMVC's verboseness and presence of HttpServlet* in method signatures turned me away. Also, why all those controllers? (Note: this has nothing to do with Spring's core, which I find very useful.) As for JSF, perhaps I didn't give it enough attention but it just seemed like it was doing too much for you also (frameworks should get out of your way, not in your way), and did you see how much documentation you have to read?! Just too complicated and heavyweight for my taste. Now for the more positive: Stripes is quite nice for its simplicity. Its author is very pragmatic and it shows in his framework. However I felt there was something missing.. I can't quite put my finger on it. I had used XWork before and I liked its integration with WebWork. Also, WebWork has nice features: Spring integration, validation, interceptors, etc. I also like how wiring is done. I started building an app but when I got into complex stuff, I just couldn't get the custom tags to do what I wanted. Again the problem with custom tags. I used Tapestry in a major project and it went really well. I did not find the learning curve to be as bad as it sounds. However in Tap 4.0 you *have* to use HiveMind and I find its also become too heavyweight. Also, it locks you in quite strongly. RIFE, on the other hand, makes it easier to decouple parts of your application. Another problem with Tapestry is that I find there are too many *tricks*. RIFE is my favorite because of.. many reasons, but to name just 2: 1. The templating. It's so Keep It Simple and Smart. There are only 4 tags to learn: B, V, BV, and I. For me that's the best part. No more having to remember tons of tags with tons more of attributes. Having to keep refering to the docs to look up attributes, what values they expect, etc. is a pain. Plus, tags tend to try to do too much for you. It all gets too complicated. Here RIFE shines by making simple things simple and complex things possible since all the logic is in Java code. 2. The modular approach. The way you build elements and wire them together is very well done. How easy it was to build that simple Table, er, "unit"? ( not 'component' ;-) ) is an example. The things that RIFE users come up with is a testament to how the framework gives you what you need to build things, without getting in the way of your creativity. OK one last thing, Geert is an awesome person and the RIFE community is extremely responsive and helpful. Not to be taken for granted! Hope this helps. Feel free to ask for any more precisions concerning the frameworks I mentioned. Frederic ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
On 7 Jun 2006, at 18:22, Geert Bevin wrote: Wait a minute.. I remember that thread! So you got ripped by whom, Wicket people? Being flamed by Wicket people Yeah, they actually went as far as having me implement an example of stateful components because they wouldn't believe me. RIFE, according to them, was just as a regular action framework. Now I have to admit that the code I pasted was based on the current work- in-progress version of RIFE, but it worked ;-) I don't understand why they would even ask for an example; it is not that hard adding state to an embedded element. Anyway, the truth is, although components are possible with RIFE, there is still a lot of work to be done to make it easy for developers to create generic components. The ordered processing of embedded elements is a good move towards that, but other features will be necessary. I am sure you are already aware of those. is like a cow's opinion - it doesn't matter. :-) Ow. Wicket has got quite some nice ideas and approaches. I think that RIFE can still steal some things from them (though not much) ;-) Exactly what I wrote in my last post: Wicket is well thought of and should be kept on the radar. Eddy -- http://coding.mu http://priscimon.com/blog ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
Actually, I tried Wicket a couple of times. It is very similar to JSF but lacks the low-level features (phase listeners, etc.) that component developers require. But, as an end-user framework, it allows one to get the job done quickly. Now, before the rifers burn me at the stake, the fact that I am still with RIFE after looking at Tapestry, JSF, Wicket and Echo -- all component-based frameworks -- says a lot. Hi Eddy, I'd be very interested to get your view on why you prefer to stick with RIFE after having tried out all these others. Particularly in the light of some comparison evaluations that will be performed by a large company next week. Best regards, Geert -- Geert Bevin Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
On 7 Jun 2006, at 18:19, Frederic Daoud wrote: So, where is that thread on JavaLobby? It's already quite old: http://www.javalobby.org/java/forums/t70272.html Wait a minute.. I remember that thread! So you got ripped by whom, Wicket people? Being flamed by Wicket people is like a cow's opinion - it doesn't matter. :-) Actually, I tried Wicket a couple of times. It is very similar to JSF but lacks the low-level features (phase listeners, etc.) that component developers require. But, as an end-user framework, it allows one to get the job done quickly. Now, before the rifers burn me at the stake, the fact that I am still with RIFE after looking at Tapestry, JSF, Wicket and Echo -- all component-based frameworks -- says a lot. Eddy -- http://coding.mu http://priscimon.com/blog ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
On 7 Jun 2006, at 18:14, Geert Bevin wrote:
private static final class TasksListTemplate extends
AbstractTemplate {
Very minor comment, it's probably better to implement the Template
interface instead.
To be proper, I should have a base abstract class implementing
Template, then derive my decorators from it.
Eddy
--
http://coding.mu
http://priscimon.com/blog
___
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Re: implementing a RIFE view component
> I don't. Each decorator applies to a particular use-case; in the > example, it is the listing of tasks. OK. I think we are addressing different cases here. In your case, you are adding functionality to a template by decorating it; in my case, I am defining a piece of template for reuse. Always the same template, just the data changes. Both useful, I think. ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
On 7 Jun 2006, at 18:06, Frederic Daoud wrote: It is simply applying the Decorator design pattern to templates. See example. Interesting, interesting.. So you decorate your Template object, but how do you decorate the HTML template? Or, put another way, how do you encapsulate how you lay out the information "title", "description", etc? Do you put this in a separate HTML template, and then use an include in the parent templates when you want to use it? Just want to make sure I understand.. Thanks! Frederic I don't. Each decorator applies to a particular use-case; in the example, it is the listing of tasks. Eddy -- http://coding.mu http://priscimon.com/blog ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Re: implementing a RIFE view component
> > is like a cow's opinion - it doesn't matter. > > Ow. Wicket has got quite some nice ideas and approaches. I think that > RIFE can still steal some things from them (though not much) I don't doubt it; I meant that when they start flaming you instead of having a healthy discussion, or become defensive at the slightest question, you become weary and figure you might as well just ignore them. Because you have better things to do. Like to try out more cool ways of using RIFE. ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
So, where is that thread on JavaLobby? It's already quite old: http://www.javalobby.org/java/forums/t70272.html Wait a minute.. I remember that thread! So you got ripped by whom, Wicket people? Being flamed by Wicket people Yeah, they actually went as far as having me implement an example of stateful components because they wouldn't believe me. RIFE, according to them, was just as a regular action framework. Now I have to admit that the code I pasted was based on the current work-in-progress version of RIFE, but it worked ;-) is like a cow's opinion - it doesn't matter. :-) Ow. Wicket has got quite some nice ideas and approaches. I think that RIFE can still steal some things from them (though not much) ;-) -- Geert Bevin Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Re: implementing a RIFE view component
> > So, where is that thread on JavaLobby? > > It's already quite old: > http://www.javalobby.org/java/forums/t70272.html Wait a minute.. I remember that thread! So you got ripped by whom, Wicket people? Being flamed by Wicket people is like a cow's opinion - it doesn't matter. :-) ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
private static final class TasksListTemplate extends
AbstractTemplate {
Very minor comment, it's probably better to implement the Template
interface instead.
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
___
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Re: implementing a RIFE view component
Hi Geert and Eddy, > Some people might rip you apart when you call this a component since it > doesn't handle any encapsulation of state (which is what happened to me > last time on JavaLobby), but anyway. Indeed, it's just a "view component", maybe "component" is not the right word. Sorry you got flamed :-( One point I'd like to make is that an example such as mine to display an HTML table, is by no means meant to be reusable "by everyone in every application for every purpose super-duper component". Far from that. I find that such attempts become WAY to complicated to use, and there's always some particular case that you want that's missing. ;-) No, instead it's just to reuse it in a particular app to reduce cut-and-paste and be able to make a change in one place to have it show up across the app. But your point about evaluating the need for behavior/interaction in order to decide to make it a component / Element, is well taken. Thanks for the info. > Which is exactly why I find components cumbersome in most cases. A > component should be relevant on its own, and to do that a developer > would have to consider many different possibilities. Agreed. That's why I don't think one should try to write a generic component for all purposes. I appreciate your responses. You have to love RIFE for being designed in such a way to allow developers to try out things like these and they just fit in and work quite well! :-) Frederic ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] implementing a RIFE view component
Which is exactly why I find components cumbersome in most cases. A component should be relevant on its own, and to do that a developer would have to consider many different possibilities. Well that's what I've been trying to solve with embedded elements. Besides creating reflective datalinks, you really shouldn't need to have to take care of anything special. You can try it out in the current snapshot of 1.5M2! :-) So, where is that thread on JavaLobby? :-) It's already quite old: http://www.javalobby.org/java/forums/t70272.html -- Geert Bevin Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Please help testing RIFE 1.5M2
Hi everyone, I'm working on the next version of RIFE (1.5) which most notably sports support for site structure declarations using annotations, stateful view components, simultaneous continuations, step-back continuations and totally XML-less applications. As of this weekend however, RIFE will undergo some heavy testing and comparisons against other frameworks by one of the biggest online retailers as a possible choice for the next generation of their website. I would like to release 1.5M2 in time for that and that's where you come in. Please help me test drive the new features and submit your ideas, problems, comments, cool examples, documentation, ... You can find the latest version here: http://rifers.org/downloads/rife/snapshots/rife-1.5M2-snapshot-20060606/ If you're trying this later than today, please check the parent snapshots directory to see if there's no newer build. Thanks for the help! Geert -- Geert Bevin Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Re: implementing a RIFE view component
> It is simply applying the Decorator design pattern to templates. See > example. Interesting, interesting.. So you decorate your Template object, but how do you decorate the HTML template? Or, put another way, how do you encapsulate how you lay out the information "title", "description", etc? Do you put this in a separate HTML template, and then use an include in the parent templates when you want to use it? Just want to make sure I understand.. Thanks! Frederic ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] implementing a RIFE view component
Geert Bevin wrote: Hi Frederic, thanks for sharing this! Some people might rip you apart when you call this a component since it doesn't handle any encapsulation of state (which is what happened to me last time on JavaLobby), but anyway. Which is exactly why I find components cumbersome in most cases. A component should be relevant on its own, and to do that a developer would have to consider many different possibilities. So, where is that thread on JavaLobby? :-) Eddy -- http://coding.mu http://priscimon.com/blog ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] implementing a RIFE view component
Hi Frederic,
thanks for sharing this!
Some people might rip you apart when you call this a component since
it doesn't handle any encapsulation of state (which is what happened
to me last time on JavaLobby), but anyway.
It's a nice example of the flexibility of RIFE's template engine though.
The main criticism of this approach is that when your table needs to
become interactive (like sorting the columns and such), you have to
reimplement your 'component'. When using embedded elements, you can
just continue to extend the capabilities of it.
Best regards,
Geert
On 07 Jun 2006, at 17:12, [EMAIL PROTECTED] wrote:
Hi dear RIFErs,
I've managed to implement a simple component which I call a "view
component", in the sense that it's not really an Element, just a
reusable unit that renders a view from some data. In this case, it's
an HTML table. My goal was to encapsulate how I display a table of
data in my application, so that it is consistent throughout.
My question to you is, what do you think of this approach? Am I
missing some important issues? Is there a better way of achieving
this? I think this way seems fine but I'm interested in your thoughts
or suggestions.
Say I want to display two tables of data. Ideally, in my template,
I'd want something like:
Here is a table:
Here is another table:
And, in my Element.processElement():
Table table1 = ...; // create a Table component from some data
Table table2 = ...; // ditto
template.setValue("table1", table1);
template.setValue("table2", table2);
So it is the Table class that is the view component. It has a
Template that could be set by injection (in my example, it is
hardcoded..) This class/template combination takes care of rendering
the HTML table from the supplied data, with any niceties that I
want (even/odd rows, CSS classes..)
So now any time I want to display a table of data, I create an
instance of Table, feed it the data, and place it in my template. The
Table.toString() method returns its template.getContent(), so that it
renders itself.
I didn't see a need to involve Element here, since the Table has no
behavior, data links, exits, etc. It is just a view component.
What you do think? Is this approach good for creating reusable
"view components" in a RIFE application?
Thanks in advance for your thoughts!
Note: if you want to try out the attached sample code, just add
the RIFE jar in the lib/ directory, then run "ant build" from the
root directory. This will build the WAR file in the "dist/"
directory.
Best regards,
Frederic Daoud
--
[EMAIL PROTECTED]
___
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
___
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Re: implementing a RIFE view component
Frederic Daoud wrote:
Hi Eddy,
Thanks for your response.. a response from "Mr. Component" himself :-)
Unless re-used a lot, components are not worth the effort, IMHO.
I like the approach, although I personally prefer template decorators.
You've got my curiosity; what do you mean by template decorator?
Could you explain or point me to a document?
It is simply applying the Decorator design pattern to templates. See
example.
Note: I can be anal about coding conventions sometimes, so I pass a bean
to setBean() instead of any object.
Eddy
--
http://coding.mu
http://priscimon.com/blog
public class ListBean {
private List elements;
public List getElements() {
return elements;
}
public void setElements(List elements) {
this.elements = elements;
}
}
public class ListTasks extends Element {
private TasksListTemplate template;
public void initialize() {
// let's decorate our original template
template = new
TasksListTemplate(getHtmlTemplate("tasks.list"));
}
public void processElement() {
List tasks = ...; // get tasks from DB
ListBean bean = new ListBean();
bean.setElements(tasks);
template.setBean(bean);
print(template);
}
private static final class TasksListTemplate extends AbstractTemplate {
private Template template;
public TasksListTemplate(Template template) {
this.template = template;
}
public void setBean(Object bean) {
template.setBean(bean);
List elements = ((ListBean) bean).getElements();
for (Iterator i = 0; i < elements.iterator();
i.hasNext();) {
Task task = (Task) i.next();
template.setValue("title", task.getTitle());
template.setValue("description",
task.getDescription());
template.setValue("dueDate", task.getDueDate());
template.appendBlock("tasks-rows", "tasks-row");
}
}
// implement other abstract methods here
}
}___
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
[Rife-users] Re: implementing a RIFE view component
Hi Eddy, Thanks for your response.. a response from "Mr. Component" himself :-) > I like the approach, although I personally prefer template decorators. You've got my curiosity; what do you mean by template decorator? Could you explain or point me to a document? Thanks again.. Frederic ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] implementing a RIFE view component
[EMAIL PROTECTED] wrote: Hi dear RIFErs, I've managed to implement a simple component which I call a "view component", in the sense that it's not really an Element, just a reusable unit that renders a view from some data. In this case, it's an HTML table. My goal was to encapsulate how I display a table of data in my application, so that it is consistent throughout. My question to you is, what do you think of this approach? Am I missing some important issues? Is there a better way of achieving this? I think this way seems fine but I'm interested in your thoughts or suggestions. Say I want to display two tables of data. Ideally, in my template, I'd want something like: RIFErs never cease to amaze! Good work, Frederic. I like the approach, although I personally prefer template decorators. Eddy -- http://coding.mu http://priscimon.com/blog ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
