I like your practical approaches as well, and share part of it. Keep express yourself freely. We need many *frank* discussions to keep things moving in a proper perspective.
Best regards BaTien DBGROUPS
Vic Cekvenich wrote:
BaTien Duong wrote:
SNIP
Craig R. McClanahan wrote:
SNIPThere is also an implicit non-goal that I should state explicitly -- I'm
totally uninterested in building in (to Struts) support for non-JSR 168
based portal servers -- be they open source ones like Jetspeed or
commercial ones (BEA, IBM, Oracle, Sun, whatever). This is for the same
reason that I'm not interested in supporting any non-Servlet-API variant
on servlets -- that's not where the market is. Providers of non-168
portal servers are welcome to provide their own adaptations of they want
to, and several of them already do.
Fortunately, all of the servers portal mentioned above (including
Jetspeed) are planning to provide JSR-168 compatible support, so
implementing 168 support into Struts is instantly useful on all of them.
That's the power of common standards.
SNIPThanks for this forcefull statement that indicates the right leadership. I totally agree with this. That is why i think Struts with the best design and least burden of past technologies is the best candidate to realize the importance of JSR-168 Portal/Portlet container and WSRP for later stage. Hope many developers / designers will join in to realize the benefits of industry standards.
many
Struts developers (i know at least a number of Portals based on
Struts-Tiles, all except basic portal, stating to support JSR-168) (i
am one of them) will seriously put some time in this refactoring process.
Yep ... JSR-168 is going to be a very popular API, quite likely rivalling
servlet in the number of server choices people will have. And supporting
it gracefully in Struts means you'll be able to deploy a Struts based app
using either servlet or portlet based servers, depending on your needs,
with minimal changes.
BaTien DBGROUPS
(Funny how we talk past each other).
If people want to market JetSlow w/ JSF (and add on EJB even ) against bP.... OK, more competition means better sofware. I market to companies that also have non Java, and want some code to execute in a browser (like Struts Menu, Validator and now Calendar tag do) and like high scalability, and easy to build.
I kind of look at PHP forums, Nukes, Zope, Plone, MS Sharepoint etc. Non of them will support Portlet API either. JCP 168 and 127 are Sun "standards" and might not become a popular standard.
( http://finance.yahoo.com/q?s=SUNW&d=c&k=c2&a=v&p=e5,m20,m100,m200,e200&t=2y&l=off&z=l&q=l
)
To say that you "could" take Portlet writen in BEA to IBM... when this can't be done for EJB (if your resume says IBM EJB, you can't get a BEA EJB gig).... and who would want to go from IBM to BEA... mostly people go from Java to C# or Javascript. That IS cross platform:
http://www.xmlrpc.com/directory/1568/implementations
(but... if you like "JetSpeed" and the JCP Portlet API, I would think you would/should use it w/JSF and not (simpler) Struts). By some definition, Struts is not a JCP standard, but it is a *defacto standard*. So JSF + Portlet are JCP Sun stanadrds (and Struts is not JCP, neither is iBaits or Hibrenate.... people still use them a lot in production ... not like some API that do not make it to production)
So what vendors think is cross plafrom and standard is not what clients I work with consider standard or cross platform.
I like KISS architecture, so as long as I am able to sell that, it works for me.
bP (aka "best Practice") example forums writen in Struts with display tag pagination, (and TilesAction, not JetSlow) WIP:
http://basicportal.com/do/articleLstPg?ID=1
(bP is free for open source and free for small start ups... and VERY cheap for others, Struts training available. It is all Struts examples, so you can write your own "standard" modules quick like)
wishing you best of everything,
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
