|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
|
Message #231369
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Another component framework-Why?
When last time I had a look at Click it seemed to use velocity templates for rendering pages. As of now Wicket seems to be a better choice. It has got a very good developer community.
How does click fare in comparison to Wicket or Tapestry,for that matter?
Finally, Is there a way of connverging all ideas into a single framework?
|
|
|
Message #231371
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Click Framework 1.2 Released
Congratulations
i tried click back at ver 0.7 and it was amazingly simple yet powerfull soln. to the view layer
its really nice and really simplifing the component architecture
one of its stenghts is documentation,well documented with UML graphs everywhere makes it extremly fast to recognise the lifecycle hence immediate start using it
BUT
as its templating was velocity based ,composing page(from each other) was not that simple and not not html designer friendly as tapestry and wicket
a second point is:the defining of the handler method and passing its name as string decrease the value of java development as there is no refactoring support
|
|
|
Message #231376
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
Why Click?
* Java web app development is insanely painful
* Tapestry has some great ideas, but it’s like “Eating an Elephant”
* Your average Java developer has a short attention span and shouldn’t be given scissors
* Had to be a better way
Comparison To Wicket
Click is much simpler and easier to learn than Wicket. The Click API has some 83 odd classes (including the Click Extras), while Wicket API in comparison has 666 classes. This is a good thing.
The Click documentation is also outstanding, leaves Wicket for dead in this area.
Other benefits include the automatic HTML generation provided by Click components, this is a big productivity benefit.
You can do quite sophisticated form and table layouts in Click Java code with out having to write reams of HTML. For example you can have a Click form with a multiple column layout, multiple fieldsets and simply have in your HTML page: $form. Of course if you want you can manually layout forms for doing very fine grained UI design.
Other Click benefits, include many more out of the box components and the ClickIDE.
Where Wicket has advantages over Click is in its support for persistent page state and AJAX.
I know of a couple of people who have used both Click and Wicked so maybe they could provide you with some additional in sites.
regards Malcolm Edgar
http://click.sourceforge.net
|
|
|
Message #231379
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
..while Wicket API in comparison has 666 classes.
Now that right there is enough to convince me that Wicket is the Devils work! ;)
|
|
|
Message #231387
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
* Tapestry has some great ideas, but it’s like “Eating an Elephant”
Malcom,
I agree with you only 99.999% on this one. I would have agreed 100% with you if you had said Tapestry is like "Eating a Dinosaur". Bacause its becoming even more bloated and overkill in Tapestry 5 as it's coming with it's own in-built IoC container. Consider building an application with a Spring layer as well. You'll end up with 2 IoC containers in your runtime. And even more insane is when you're integrating these layers with an EJB3 layer- you'll end up with 3 IoC runtimes.
I know, web development is complex. But does a webframework need its own IoC container? Ok, maybe it needs some sort of DI, but then my next question would be why can't the DI be delegated to other frameworks. Especially in times when there exist already matured IoC frameworks like Spring?
Howard's fingers itch so much he always wants to re-invent the wheel. Take a look at the history of Tapestry releases. Every major release was a re-write of the previous with little consideration to backward compatibility.
For me this is sufficient reason to shy away from Tapestry.
BTW, during googling sometime back, I learnt theserverside was implemented with Tapestry. But I also heard recently that they've replaced a big proportion of the Tapestry part with Webwork. What does this say about Tapestry?
Jan
|
|
|
Message #231393
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
+1 on the Tapestry rewrite. I was seriously looking at Tapestry as an upgrade option from Struts. The v4 release broke v3, but I believe I read that this was done to create a new foundation moving forward. I don't quite buy into the Hivemind philosophy, but there you go. I figured, let v4 simmer and we'll take a look...
However, when v5 came out, broke v4, put up another IOC container saying how it was also better than Spring(the same claim being made by the Hivemind integration) I just couldn't take it seriously. I mean, why wasn't Hivemind good enough? And if it wasn't, why gamble on the current claims of the new IOC container or even Tapestry?
Sorry. I wouldn't risk my job on it.
|
|
|
Message #231401
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax integration
Perhaps I missed it but I didn't seen any mention of Ajax integration in the documentation I quickly perused. Does it exist? If not, is it going to be added? It would be nice if the components provided Ajax functionality without the pain of the developer having to somehow integrate it manually.
|
|
|
Message #231408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax integration
Perhaps I missed it but I didn't seen any mention of Ajax integration in the documentation I quickly perused. Does it exist? If not, is it going to be added? It would be nice if the components provided Ajax functionality without the pain of the developer having to somehow integrate it manually.
There you go - future bloat requests are already dooming Click.
People will be saying in a year or so that Click version 5 has become too bloated with its own IoC container, AJAX components, service layer, etc. Time to move to the "Quick'n'Lean" framework version 1.01 because development on that bloated Click framework has become too difficult. It provides only the basic features you need to get up and running.
Sorry, I don't mean to be bashing Click, per se. Just noting a pattern in framework design/software engineering in general.
Another example:
EJB because Corba is too hard and bloated.
SOAP services, because EJB is too hard and bloated with all those transactionality, security, and guaranteed delivery services.
No wait, REST services, because SOAP services are too hard and bloated with those WS* technologies - transactionality, security, guaranteed delivery, etc.
No wait, AJAX/JSON services because XML is too heavy.
No wait, ...
|
|
|
Message #231412
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax integration
First off, I didn't request anything. I asked a couple of questions.
Secondly, even if I did ask them to add Ajax support to Click it doesn't mean that it will suddenly (or ever) become bloated and unwieldy.
Thirdly, Click (according to their website) is designed for use in enterprise development. Nowadays crap like Ajax is simply expected. Sticking your head in the sand and ignoring that fact is akin to telling your market you don't give a crap about their needs. What's the point of being lightweight if nobody uses your framework?
I grant you that many frameworks are bloated but I've found that most of them pretty much started off that way. You can usually see it in the design of the framework early on. Click, on the other hand, doesn't give me that feel at all.
|
|
|
Message #231418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax integration
Click does not support AJAX out of the box, however its pretty easy to integrate simple AJAX stuff. For example:
http://www.avoka.com:8080/click-examples/ajax/ajax.htm
With most of the web applications I do, they have a little bit of AJAX here and there make the app feel more responsive. This is usually done on Select controls where you want to dynamically populate a list based on some other selection.
I use the the Rico library in Click, as it has some cool feature and is very easy to use.
If you have really crazy AJAX UI requirements, I think you would be better using Flex rather than some Java web application framework.
regards Malcolm Edgar
|
|
|
Message #231424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
..while Wicket API in comparison has 666 classes.
Now that right there is enough to convince me that Wicket is the Devils work! ;)
i will quickly make one class more....
|
|
|
Message #231425
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Click Framework 1.2 Released
Yet Another Web Framework ? Why didn't you contribute to Wicket ?
|
|
|
Message #231426
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How does Click stands against JSF?
I want to move away JSPs to a component framework. I have some experience with JSF and I was thinking this could be an option.
We are currently using Spring MVC. Initially I want to do replace JSP as the view technology, but keep Spring MVC for the other parts. Later on, I might replace the whole presentation framework.
What are the advantages of Click over JSF? Can I use click with Spring MVC?
Any help would be greatly appreciated.
Thanks.
|
|
|
Message #231429
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How does Click stands against JSF?
>>Can I use click with Spring MVC?
Spring MVC is a action framework, so you have to use Click or Spring MVC, not both.
But you can use Click with Spring, as the IoC container.
>>What are the advantages of Click over JSF?
I have evaluated both of them, and I found click easier. If you are going to use JSF, you probably use Facelets, Tomahawk, etc. Click also has goog view components (tables, panels, dateCalendar,etc). This kind of questions is difficult to answer.. sometimes it starts a new framework flame war. I guest you should evaluate both and take your conclusions...
The first time I take a look at Click, I was using WW2.
After read the click documentation I was very impressed with all the features and with the click 'simple' design.
So that was my last ww2 project :-)...
There's 6 months I'm using Click and I'm very satisfied with the results, since I can finish my application quickly and click has also an excellent performance.
With Click, Wicket you can use OO, so it's possible to reuse more code. That's a good point. For example you can do a crud page like that:
public class PersonCrudPage extends CrudPage{
protected Object getModel(){
return Person.class;
}
}
And the abstract CrudPage does all the stuff. In the view layer I just have to write $form, that's done.
Sometimes all the screens in the applications looks equal, so in my point of view doesn't make any since repeating my self, and write HTML + actions all the time. With Click I can reuse my pages. This is why I moved from WW2 to Click. WW2 does it job very well, it is an amazing framework, but I realized that for me, the Click 'Component and Page Oriented design' works very well.
Sometimes there is some desired features that Click doesn't have, like AJAX, as said before. But is easier to customize the framework. You just need to override the toString() method of some Component and render some AJAX stuff, using some library like prototype. But of course, nowadays you need do it by yourself.
regards,
|
|
|
Message #231430
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
BTW, during googling sometime back, I learnt theserverside was implemented with Tapestry. But I also heard recently that they've replaced a big proportion of the Tapestry part with Webwork. What does this say about Tapestry?
Jan
Obviously, I'm not privy to the thinking inside TechTarget, as I haven't been involved with them since Jan 2005. When I last worked with them, they were quite appreciative of what Tapestry was offering them, but they only had two developers working on the site.
It is likely that they wanted additional functionality in the discussion forums; they may have faced a buy-vs-build decision. Further, it is likely that they were offered the software for free (much of the TheServerSide infrastructure back in 2004 was donated by companies for the exposure). So in that likely situation, you can see how they might swap out portions of the site in favor of Jive.
As to the rest of your post; well Jan you can tied up about technology decisions that are irrelevant, such as the number of IoC containers (you miscounted, the servlet container acts like an IoC container in a limited fashion, so no we're up to four. And most application servers are built around something IoC-like that's not visible to the user, so now it's up to five and counting).
But that technology is not interesting compared to what T5 buys you, which is a lot. Further, I've been able to simplify many things between T4 and T5 so that Spring will integrate as a first-class citizen.
I've begun showing off T5 to users at my No Fluff Just Stuff speaking engagements and it floors everyone who sees it ... and I haven't even started on adding the Ajax support to it.
T5 is the first *rewrite* of Tapestry since January 2000. There have been a few refactorings and reworkings since then, but the core code I wrote back then has served quite well; Jesse has been doing amazing things with Tapestry 4.1, seamlessly integrating client-side events into server-side method invocations. However, my inexperience at the time in creating the API, and the lack of modern tools such as annotations and Javassist, meant that adding new features almost always involved a break in backwards compatibility.
The new code base is designed for productivity and efficiency and a minimal API. Much is available via naming conventions and annotations rather than rigid interfaces. I doubt there will even need to be a Tapestry 6, but compatibility in later Tapestry 5 releases will be a first class citizen.
|
|
|
Message #231435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
Howard,
I am a real fan of Tapestry and have used it successfully on a lot of projects. Some of the things about Tapestry that could do with some improvement are
1. Lack of good books or tutorial support. There are hundreds of such books and tutorials on Struts for example. Without such a support its hard to really get up an running with Tapestry.
2. The only real book out there is your book but its still on Tapestry 3. The book by Tong Ka Iok is about Tapestry 4 and its a great but its really the only one out there.
Given that Tapestry requires you to know a lot before you can start implementing websites using it, that acts as a serious hinderance.
At the very least can we have good documentation on Tapestry 5 with
a. Examples on how to implement key features
b. How do you integrate with Spring, JSP and STRUTS for example. On my previous project I had a real hard time integrating Tapestry 4 with Spring, hence that would be real benefit.
c. From the outset a "File download" component like an "File upload" one. This one is so frequently needed and while I built my own I wish I had it.
Your book library application is great but its only useful when you know the nuts and bolts, hence it is very important for good and through tutorials depicting all features (like the book you have) to really get people on it.
I am going to starting a new project in October and it would be great if Tapestry 5 is available by then as given all the stuff I am reading it makes less sense to go with Tapestry 4.
Thanks,
Sameer
|
|
|
Message #231437
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How does Click stands against JSF?
Thanks Ricardo for that. I will take a better look at Click.
I am thinking that it might be possible to use JSF & Spring MVC. If I tell Spring MVC to render *.jsf views, I guess JSF will take control and render the page. Of course, I would not be able to uses events and things like that. All buttons & links will point to a Spring MVC action. In other words, I will use JSF to render my components and Spring MVC to control the flow, exceptions, ect.
I don't know if this is possible. I will try & see.
Cheers,
Mauricio.
|
|
|
Message #231441
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How does Click stands against JSF?
I want to move away JSPs to a component framework. I have some experience with JSF and I was thinking this could be an option.
We are currently using Spring MVC. Initially I want to do replace JSP as the view technology, but keep Spring MVC for the other parts. Later on, I might replace the whole presentation framework.
What are the advantages of Click over JSF? Can I use click with Spring MVC?
Any help would be greatly appreciated.
Thanks.
I haven't worked with JSF so I can really compare them. If you are using JSF I would imagine you would want to use one of the GUI tools to be productive. Otherwise you would probably need to be pretty hard core, if you to do it by hand.
One of the things I don't like with the JSF approach is that you have lots of bits and pieces to manage, including Objects, JSPs, Tags and XML configurations. With Click its pretty well configuration free, you have a Page class where you do most of your work. The Page HTML template tend to be very simple, usually with a $form and $table reference.
Most Click applications have a border HTML template which wraps your page HTML template. This is where you invest your time on the applications look and feel. The nice thing about this approach is that you only need to do it once.
If you are using SpringMVC, I would recommend keeping the Spring IoC container with all your business stuff, and replace the MVC part with Click. Click has good support for Spring IoC, using the ClickSpringServlet. The online click-example application uses Spring for the IoC container and Cayenne for the ORM framework.
regards Malcolm Edgar
|
|
|
Message #231445
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How does Click stands against JSF?
Hiya Malcolm, congrats on the release, looks good.
I have to admit I have never understood all of the angst against JSF. I would imagine it is from people whom have used it without facelets.
It isn't light-weight however - there is quite a learning curve for new users (less so for those with asp.net experience).
I've used JSF on several projects, and in my experience it (coupled with myfaces/tomahawk/facelets/spring/hibernate) makes for a superbly productive combination.
ATM, I'm been looking at tibco general interface with spring/xfire/hibernate.
So far it seems amazing quick to build a responsive AJAX gui talking to the back-end with SOAP requests.
Have you had a serious look at TIBCO GI and it's (limited) competitors?
(As an aside: could it finally be a decently technology for portlets?)
Best Regards,
Hugh
ps: I know GI has been around for a while but these days it works in more then one browser :)
|
|
|
Message #231447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Form generation?
I'm looking for a UI component composition oriented framework that includes html form generation functionality.
I.e. the option to have crud screens generated for a particular bean, including server side validation, rather than having to hand code, or even compose them myself.
Is that what was meant by 'Automatic form rendering and client/server side validation'?
|
|
|
Message #231449
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
Comparison To Wicket
Click is much simpler and easier to learn than Wicket. The Click API has some 83 odd classes (including the Click Extras), while Wicket API in comparison has 666 classes. This is a good thing.
Wicket might have a lot of classes, but how many of those classes are users expected to interact with? And how many of them are just some utility classes, or internal?
Besides, why would I learn Click? Maverick/Struts have like twenty classes! So it must be better. Servlets have what, like ten? Even better!
The Click documentation is also outstanding, leaves Wicket for dead in this area.
I didnt know Click has a book out, and another one on the way.
Other benefits include the automatic HTML generation provided by Click components, this is a big productivity benefit.
Also possible with Wicket, but not out of the box. This is great for prototyping fast, but why rewrite that stuff when its time to go to production? Whenever I have used a framework that provided auto-html generation in the past, we always had to tweak it so much that it become a huge pain. It was much easier to simply write the entire html for the page and be done with it. Besides, input type="text" wicket:id="tf". Did you clock that? How long did that take to type you think?
You can do quite sophisticated form and table layouts in Click Java code with out having to write reams of HTML.
For example you can have a Click form with a multiple column layout, multiple fieldsets and simply have in your HTML page: $form. Of course if you want you can manually layout forms for doing very fine grained UI design.
It has always been our philosophy that html+css is a much better language for doing web layout then java. Feel free to disagree of course.
Other Click benefits, include many more out of the box components
You are kidding right?
and the ClickIDE.
Have you seen wicket-bench?
Where Wicket has advantages over Click is in its support for persistent page state and AJAX.
Other advantages include:
Wicket is object oriented - since click doesnt handle state for the user it cannot be called object oriented.
Wicket is component-oriented, not page-oriented. That means components can easily embed other components, and you are not limited to page-driven design. Eg a wicket application can consist of a single page, with all the other parts being swapped in and out across the lifetime of that page instance, like a desktop app.
Wicket has 666/667? classes, that means you can find something that will fit your needs almost exactly, rather then having to roll your own.
|
|
|
Message #231453
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
In my opinion, Click is quite nice, certainly compared to a lot of other alternatives (I would pick it over any model 2 framework at any time). If it is simplicity you are after AND you are developing relatively simple user interfaces, it may be a better pick than Wicket, which - I agree - probably has a higher learning curve. However, I do think that if you get into more complex tasks, you'll be able to maintain a clean programming model with Wicket, whereas with Click you'll have to start stacking workarounds.
The good (imho of course):
* small code base, thus easy to dig through
* well documented API
* pragmatic, while still providing what seems to be a decent programming model (at least as long as Click suffices for what you want to do).
* like Wicket, it has header contribution support.
* Uses Velocity, which imo is a much better alternative to JSP.
The bad:
* It's quasy OO at best (no automatic state handling, no real fine grained control over how components are created, etc)
* like Tapestry, it is page oriented rather than component oriented. This severely limits the level of reusability that can be achieved.
* The other side of having a framework that is 'simple and lightweight' is that it only supports relatively simple cases. This doesn't have to be a problem if it is easy toextend it's capabilities, but from the couple of hours I played around with it, I thought it really was a bit too basic for my taste.
See also http://www.nabble.com/Creating-Entire-Forms-in-Java-Code-Only--tf3545176.html#a9946324
|
|
|
Message #231454
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
* Uses Velocity, which imo is a much better alternative to JSP.
One more note about that is that I'd prefer a real clean separation of presentation and logic, and using Velocity violates this. But I understand that some people prefer a more scripting based approach, in which case I would prefer Velocity over JSP. So I guess it is a relative + :)
|
|
|
Message #231455
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Form generation?
Is that what was meant by 'Automatic form rendering and client/server side validation'?
No.
Automatic form rendering is because if you create a Form object and add some controls (TextField, Checkbox) it will generate the html source code automatically. Of course, you can do it manually too.
And client/server validation because the Form will validate the fields on the server side (required fields, number, dates, regex, etc)...
And if you set form.setJavaScriptValidation(true) it will generate the javascript validation in the client side.
|
|
|
Message #231456
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How does Click stands against JSF?
Hiya Malcolm, congrats on the release, looks good.
I have to admit I have never understood all of the angst against JSF. I would imagine it is from people whom have used it without facelets.
It isn't light-weight however - there is quite a learning curve for new users (less so for those with asp.net experience).
I've used JSF on several projects, and in my experience it (coupled with myfaces/tomahawk/facelets/spring/hibernate) makes for a superbly productive combination.
ATM, I'm been looking at tibco general interface with spring/xfire/hibernate.
So far it seems amazing quick to build a responsive AJAX gui talking to the back-end with SOAP requests.
Have you had a serious look at TIBCO GI and it's (limited) competitors?
(As an aside: could it finally be a decently technology for portlets?)
Best Regards,
Hugh
ps: I know GI has been around for a while but these days it works in more then one browser :)
Hi Hugh,
Nice to hear from you, I hope New Zealand is treating you well.
Regarding JSF and Java web frameworks, I think if you are productive in with your current stack you would be mad to drop if for another stack. It simply takes along time to become proficient at them. On one job we swapped out Struts for SpringMVC (once Action pattern framework for another) and any productivity benefit was pretty well lost in the downtime getting staff up to speed on the new web framework.
Never heard of TIBCO GI, I thought they made expensive messaging buses. I will take a look.
regards Malcolm
|
|
|
Message #231460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How does Click stands against JSF?
Heya,
as mentioned - it's the Sydney hugh not the NZ one - although when we worked together Walcott and I had this problem all the time :)
Someone elses comment about moving to component based versus page based is pertinent, imho we need to leakily abstract into a component model to chase asp.net (aka JSF on the server side or TIB GI on the client side).
cheers
|
|
|
Message #231467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
I've begun showing off T5 to users at my No Fluff Just Stuff speaking engagements and it floors everyone who sees it ... and I haven't even started on adding the Ajax support to it.
Well Howard, of course you'll blow already Tapestry users to the floor when you boast about T5 to them.
Developers get quickly fed up with particular way of doing things that becomes a routine and get always excited when a new way is introduced. So I can imagine the enthousiastic reactions from them. T5 can be innovative and productive but the real challenge would be selling it to new users.
I've read your opinions in the past times and what I gather is that you place more emphasis on productivity and simplicity and less on making the learning curve of Tapestry less steep. A simple analogy is sometimes a piece of code of 10 lines being more comprehensible than a compact 3 lines equivalent that is labeled simple. With Tapestry 5, you're introducing another beast and bloat that would even be harder for newcomers to grasp. And also hard to explain in a book to beginners. And in the end no publisher would bet on a book contract with you. Like Tapestry in Action failed miserably.
Because of your track record of breaking things, another challenge you'll face would be luring new users and keeping them.
Tapestry has proved itself to be so fragile that a serious organization would be reluctant to consider it. Unless, of course there's a gun pointed to their head.
I doubt there will even need to be a Tapestry 6, but compatibility in later Tapestry 5 releases will be a first class citizen.
Ok, Howard, I believe you on this one. Because, left alone you, Tapestry 5 would now have been called Tapestry 4.5 or so.
I've been a Tapestry user and followed the discussions on the Tapestry list about which version name to give to the
the then next (currently Tapestry 5) release of Tapestry. You insisted on sticking with a 4.x until the mass protested and you changed your mind to go with a version 5. Some even thought the changes planned were so drastic and radical that it didn't even deserve the Tapestry title.
So with this comment I've gotten even more scared of you because you might in the future bundle some radical changes
in a 5.x series. Readers and Tapestry users, beware!
Jan
|
|
|
Message #231483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Golly gee whiz guys....
You have me blushing here. Once again you've managed to take a thread about a completely different framework and spend the majority of the time discussing your insecurities about the framework you fear most - Tapestry.
I can't blame you I guess ....but sometimes I'm not sure you realize how it looks after a while...It's always the same people posing the same arguments.
We keep chugging along anyways. Always the first to innovate and always the first in line for your public deranged ranting.
Me thinks though doth protest too much no? ;)
|
|
|
Message #231489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Golly gee whiz guys....
Jesse,
Why do think I'm scared of Tapestry? Why would I be scared of Tapestry when I don't have any competing product. Like I've mentioned on a thread here before, I've been a Tapestry user but got disappointed and frustrated by the craziness and all the hassles that came with any new release. I'm now a GWT user, and I didn't develop GWT. I'm also not on their developers list.
I just want to open up things so that any current and future Tapestry user would make an informed decision based on what the future holds for them if they decide to go with it.
As usual, I'm sorry you couldn't pick on some of the points I've mentioned in my previous posts but make those childish and baseless generalizations about my them. I didn't expect that from a Tapestry commiter. I expected a wiser response.
Jan
|
|
|
Message #231491
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Golly gee whiz guys....
Oh I know Jan. You are just an innocent asking reasonable questions and being a good citizen right?
The only problem with that logic is that it's always the same reasonable answer to the same reasonable "points" that you post in every Tapestry related thread. I've responded to those duplicate sets of points a number of times already - one has only to click on your name to see that.
So I believe you, I ~really~ do. Wink wink, nudge nudge. ;)
...I just want to open up things so that any current and future Tapestry user would make an informed decision based on what the future holds for them if they decide to go with it...
|
|
|
Message #231516
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Another component framework-Why?
Where Wicket has advantages over Click is in its support for persistent page state and AJAX.
Great advantages to use Wicket... :) Thanks for the info! :P
|
|
|
Message #264608
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My impressions on Click ... in July 2008
I have been using Click Framework for over four to five projects this past year and here's my impressions on the framework. But before I go on, I would like to say that before I worked with Click, I have used Struts 1.1, Web Work (currently Struts2), Spring MVC and Wicket. And so far out of all the frameworks, I find Click very simplistic in nature. WebWork (Struts2) would be my second choice. I think one of the drawbacks of Java compared with Ruby is that we end up writing 20 lines of code for a Hello World and scripted languages like ruby and python can do that with one or two line(s). My point here is not to say one language is superior to another. Each has it's place. But I feel that Click takes on the simplistic natural path for development.
Traditionally, what most of us have gotten used to is the MVC model where the model is in a Form-Bean and the view is usually in a JSP page and the controller has the guts of how to drive between the two. Click and Wicket take a different approach (they are component based framework - like Tapestry)- where you lay down the html-form as a brick and mortar approach... you lay down one brick at a time as form-components and you let the "velocity" engine do the rendering. And of course, if you are not happy with the default layout, you can override it down to the nitty-gritty areas... And in the same way, you build event methods and attach them to buttons, anchor tags etc... so upon press it invokes the appropriate method to process which neatly lends itself to the Comet-Ajax approach we are getting to nowadays.
But by comparison with Wicket, I find Click far easier to work with. Intuitive and elegant. And the base widgets available within Click are very clean and sharp. So far I have not had a need to add any new widgets for any the projects I have dealt with. The only gotcha or issue I came across is the in the Extras provided called the 'menu' widget. The Security model is tied closely with the application containers (Tomcat/WebLogic/Web Sphere) JEE declarative security model. And at this present time the Menu component is tied closely with the containers security so I ended up implementing my own menu component. I wish there was a way to override the "isUserInRoles()" method of Menu to implement against my own form-based authentication for the web site.
And time-wise, I have noticed that I'm spending less time writing code and more time enjoying the simplicity of coding (which I call the zen-effect) as experienced when you code in Ruby or Python.
I have to say congrats to the developers behind Click for coming up with a simple, elegant framework that makes the development a joy... And if you haven't given Click a try you should...
http://click.sourceforge.net/
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
