Guess what? I need an "if component" now (to change some visual attributes). Of course, I could code the component but I really prefer to do it in a declarative way à la JSTL. Tags file weren't invented for nothing afterall so I guess Shale should follow this direction too. I'll probably try to implement it myself if I have enough time tonight.
On 12/4/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > Look great to me. I am just wondering how sessionScopeVar is working? Is > it > > like the "var" argument in JSTL? > > > > > Yep, it's like the var. Maybe it would be better to name it "var" and > provide a "scope" attribute for request or session. I went with session to > avoid the same questions about the updatable dataTables. > > The difference is that the target "sessionScopeVar" object will be a map > and the keys are generated to match the generated el for the substitution of > the @managed-bean-name symbol. This allows the default decoding to work > without having the responsibility of the dataTable component. > > > By the way, what I like about this approach is that we don't have to > hide > > everything behind JSF components. I was wondering why I would need to > write > > a list component while in fact a list or a table is just a specific use > of a > > forEach component. It will allow developpers to develop simple > components > > quickly just by reusing basic building blocks :) That was a big weakness > of > > JSF in my mind to always have to write code to develop new components. > So > > great job! I love this feature. > > > > > Cool. These "amalgam" functions are a mix of runtime Clay binding > events. Kind of a dynamic flavor of the XML and HTML configs/templates. > > > > By the way, maybe you should consider in your design that some more > logic > > components might be add in the future (I don't know how many Tapestry > has > > but it should give us a good estimation). So I guess putting that in > > ClayAmalgam is fine for the moment but it can become bloated over time. > Just > > my two cents. > > > > I agree about the bloating of the ClayAmalgam class. Even if it was > organized similar to the JSTL libraries (c, fmt, x,..) it would be > bloated. I guess we could break each function out into a separate class. > Then we might have ClayAmalgamImport, ClayAmalgamOut, > ClayAmalgamForEach. Or, make "ClayAmalgam" the managed bean name of a map > in application scope that contains Out, Import and ForEach entries. Maybe > it will be more clear when we have a few more. > > > > > > -- > > Alexandre Poitras > > Québec, Canada > > > > Gary > > > -- Alexandre Poitras Québec, Canada
