date:20060329

Re: Playing round with 1.5 features

2006-03-29 Thread Werner Punz

Travis Reeder schrieb:
 I'm all for anything that makes component writing easier, it's pretty
 complex right now, so many places to make mistakes and makes it hard for
 a newbie to start making components. 
 
Actually there are two areas which components probably have to tackle
api wise.
a) The number of artefacts and glue code which are a huge burden
b) The way the markup is generated.

The renderers have the basic problem of having to handcode the markup
via sending strings to writer objects. This gives maximum performance
due to linear runtime complexity, but is a huge burden on the component
developers.

a split between data and markup rendering programmingwise would be saner.
pushing the whole subrendering into something more readable would
improve comfort. For instance if they subrendering could be pushed into
something like velocity you suddenly would have the component, the
bingings to the jsp or whatever subsystems and the renderer basically
would be gathering data (mostly just pushing the component directly in)
and then rendering it away via a sane templating markup.

The main problem I see is performance, so in the end we probably are
stuck with it or have to move over to client side componentization
(which is the other approach, omit the api entirely as much as possible
and move to a higher abstraction level like facelets do it)

myfaces scrolling

2006-03-29 Thread Srinivas Surapaneni

getScrolling() _javascript_ function is not being generated in the portal environment?

Is this function being generated by the extension filter?

Re: Status of New Release

2006-03-29 Thread Sean Schofield

I haven't reviewed those discussions.  Are any of these issues so
problematic that we don't want to release for several weeks?  That's
the real decision here.  I agree that its a bit awkward to have to
configure the logging with shared_impl and shared_tomahawk but
ultimately I think the benefits of the shared solution outweigh the
problems.

Whatever solution we come up to solve the shared problem, its likely
to have a few drawbacks.  So my vote would be to go forward.

As for the sandbox, that's not an issue right now since we are
planning on releasing the core for now (and then tomahawk.)  So we can
cover that when the time comes.

Sean

On 3/29/06, Dennis Byrne [EMAIL PROTECTED] wrote:
 Basically I think the plan should be to merge down this single change.
  Create new branches for the core and shared.  Release shared.  Test
 Core and release core.  Before making the new branches I will change
 the dependency to the latest shale-test which is now available.

 Were there any conclusions from the discussion Mario started a while back?  
 There are a lot of classes that use scoped objects keyed by package name.

 What do we tell people about logging ?  Currently people have to do things 
 like this:
 org.apache.myfaces.shared_impl.StateUtils=TRACE
 org.apache.myfaces.shared_tomahawk.StateUtils=TRACE

 Any conclusions on Simon's static logger discussion ?

 I will help fix any of these.

 Dennis Byrne

Re: Playing round with 1.5 features

2006-03-29 Thread Craig McClanahan

On 3/28/06, Werner Punz [EMAIL PROTECTED] wrote:
Craig, the Shale Tiger extensions are a good startin point, I read thedocs, and liked what I saw. (I also highly recommend Seam which drivesannotations to the extreme)Yep ... good stuff there too.
Anyway, having had to hack components again for an extende period oftime I still hate the huge mess the whole component API is in (no
offence to the Sun guys they did their best given that they had toenforce 1.3+ JDKs)What I would like to see would be a single controller and view objectwith all the taglib binding exposed via annotations instead of having to
drag around an extra tag class, an extra tld and an extra faces-configentry.Components for instance are the perfect place to get rid of the xmldefintions totally (which then can be overridden with application level
xml definitions if someone wants to use his own renderer)I was constrained in the stuff so far by what could be accomplished at runtime -- and there's no way to define a tag library on the fly at that point. But what you're describing could certainly be done by processing annotations at compile time instead (using apt or equivalent). That'd be an interesting area to explore, over and above the runtime stuff.
I'm game to work on that for Shale. There's a couple of other useful things to do at compile time ... like a tool to audit the configuration files that do exist to catch silly mistakes like wrong class names for managed beans.
With a good use of annotations we could cut down from two xmldefinitions and 3 classes, to two classes and 1-2 annotations in the
controller and view.Which means a total cut down of the code of at least 30% average and atotal cutdown of artefacts from 5 to 2.Craig

54 matches

Mail list logo