[16:55:22] <balunasj> mojavelinux: Nice to see you in the space ;-)
[16:56:04] <balunasj> Here is the current agenda for the Seam/CDI/RF integration meeting
[16:56:05] <balunasj> http://community.jboss.org/wiki/CDISeamRichFacesIntegrationMeetingAgenda3-11-2010
[16:56:14] <balunasj> is Lincoln here?
[16:56:29] *** balunasj is now known as balunasj_biam
[16:57:47] <mojavelinux> I just tweeted it, so that might get his attention
[16:58:20] <nbelaevski> mojavelinux: hi Dan
[16:58:20] *** lincolnthree has joined #richfaces
[16:58:25] <lincolnthree> morning
[16:58:26] <mojavelinux> yo nick!
[16:58:32] <mojavelinux> ah, there's the man ;)
[16:58:33] <mojavelinux> hehehe
[16:58:41] <lincolnthree> "the man"... nice
[16:59:13] <mojavelinux> to set the tone, Jay, can I mention the thing about the group name?
[16:59:17] <nbelaevski> lincolnthree: hi Lincoln
[16:59:25] <lincolnthree> @mojavelinux, never
[16:59:39] *** balunasj_biam is now known as balunasj
[16:59:39] <lincolnthree> hi nick :)
[16:59:43] <balunasj> I'm back
[16:59:50] <mojavelinux> I see, that's how this is going to be
[16:59:54] <balunasj> lincolnthree: mojavelinux : hi guys thanks for joining
[16:59:55] <mojavelinux> hehehe
[17:00:40] <balunasj> mojavelinux: about the group name - NO ABSOLUTELY NOT
[17:00:41] * lightguard_jp thinks he'll just lurk and watch the creative juices flow
[17:00:48] <balunasj> mojavelinux: just kidding ;-)
[17:00:52] <lincolnthree> drink the kool-aid
[17:00:58] <balunasj> mojavelinux: go ahead
[17:01:10] <mojavelinux> in the spirit of integration and coordination
[17:01:17] <mojavelinux> and my focus on building community
[17:01:17] <balunasj> lightguard_jp: lincolnthree did :-P
[17:01:36] <mojavelinux> I've long recognized that we don't really have a name for all the projects that we blog about on in.relation.to
[17:01:58] <mojavelinux> what is the glue that brings us together, and motivates us to have coordination
[17:02:22] <mojavelinux> so after some offline discussion
[17:02:32] <mojavelinux> we came up with a working name we'd like to propose
[17:02:37] <mojavelinux> Pete's suggestion
[17:02:47] *** edburns has joined #richfaces
[17:02:48] <mojavelinux> Application Developer Platform (group)
[17:02:52] <mojavelinux> or App Dev for short
[17:02:59] <edburns> mojavelinux: Dude, I've never seen you on IRC before.
[17:03:13] <edburns> mojavelinux: glad to see you here.
[17:03:17] <mojavelinux> the idea is that the focus who consume what we do...those are application developers (some might say web developers)
[17:03:20] <balunasj> edburns: Hi ed - slumming it today, or just here to see what mojavelinux does in IRC ;-)
[17:03:22] <edburns> mojavelinux: Try to hang out on ##jsf some times.
[17:03:26] <mojavelinux> and in the end, that is what unites what we are creating
[17:03:31] <mojavelinux> edburns, hey Ed
[17:03:33] <edburns> balunasj: the latter.
[17:03:41] <edburns> balunasj: I saw Lincoln's tweet.
[17:03:47] <balunasj> edburns: hey - I worked hard to get him to show up here - don't temp him away :-)
[17:03:57] <edburns> lincolnthree: Hey, I want to see you on ##jsf too sometimes.
[17:04:07] <mojavelinux> The group is a loose knit collection of projects, but one which people often view as a unified front
[17:04:31] <mojavelinux> Seam, Hibernate, RichFaces, Bean Validation, CDI/Weld, ...
[17:04:33] * balunasj mojavelinux is doing a fair job ignoring us....
[17:04:33] <lightguard_jp> edburns: Guess I should join there too
[17:04:43] <lincolnthree> **shhhhhhh*** :)
[17:04:58] <mojavelinux> balunasj, hehehe, you sound like my wife now ;)
[17:05:07] <mojavelinux> balunasj, "I think you are ignoring me right now"....
[17:05:10] <balunasj> ouch...
[17:05:13] <mojavelinux> no, just focused
[17:05:16] <mojavelinux> hehehe
[17:05:17] <lightguard_jp> lol
[17:05:38] <mojavelinux> so back to the topic
[17:05:40] <balunasj> ok lets get serious now.
[17:05:49] <mojavelinux> basically, when we address the community
[17:05:56] <mojavelinux> whether it be in a talk, IRC or blog
[17:06:29] <mojavelinux> we can really establish the connectedness by using the term "App Dev" or Application Developer Platform to show we are thinking about the whole picture
[17:06:32] <mojavelinux> so there you go
[17:06:35] <mojavelinux> our group name ;)
[17:06:45] <mojavelinux> no longer "the in.relation.to crowd"
[17:06:46] <mojavelinux> hehehe
[17:06:59] *** explosiv0SX has joined #richfaces
[17:07:04] <lightguard_jp> mojavelinux: Along with that, will there be App Dev release packages?
[17:07:19] <mojavelinux> I think it's more of a community thing
[17:07:21] <lincolnthree> "JBoss App Dev Group"
[17:07:27] <balunasj> mojavelinux: agreed
[17:07:36] <lightguard_jp> Ah
[17:08:02] <lightguard_jp> Blog space and maybe new IRC channel then?
[17:08:05] <mojavelinux> and a big part of why Lincoln and I are pushing hard to have sfwk.org back under jboss.org, so this type of meeting doesn't seem so much of a stretch
[17:08:16] <balunasj> mojavelinux: it is good to get a general identity for the different technologies
[17:08:25] <balunasj> Blog space is in.relation.to
[17:08:29] <mojavelinux> balunasj, exactly
[17:08:46] <balunasj> IRC I think is based on tech ( richfaces, seam, etc... )
[17:08:52] <mojavelinux> one final note
[17:09:12] <balunasj> mojavelinux: lets not spend too much time on this, we have a fair amount to cover for bi-weekly meeting
[17:09:31] <mojavelinux> the term "App Dev" also works because the developers that use these technologies are often in the "App Dev" group in their own company...we make it, they build with it
[17:09:33] <mojavelinux> a connection
[17:09:38] <mojavelinux> moving forward
[17:10:23] <balunasj> mojavelinux: agree with you.  Anything else on this for now?
[17:10:31] <mojavelinux> balunasj, nope, let's launch into it
[17:10:38] <mojavelinux> balunasj, the meeting that is ;)
[17:10:42] <balunasj> ok just for those that may have missed it
[17:10:45] <balunasj> here is teh agenda http://community.jboss.org/wiki/CDISeamRichFacesIntegrationMeetingAgenda3-11-2010
[17:11:00] <balunasj> This is the first of regular bi-weekly
[17:11:15] <balunasj> meetings between the RichFaces, Seam, and CDI project.
[17:11:38] <balunasj> We'll be discussing primarily integration concerns between the groups
[17:11:51] <mojavelinux> balunasj, (within the group)
[17:11:53] <balunasj> but also other technologies that effect all projects
[17:12:22] * balunasj guess who the writer is in the group.....
[17:12:24] <balunasj> :-P
[17:12:55] <balunasj> especially JSF 2
[17:13:44] <mojavelinux> balunasj, our favorite technology ;)
[17:13:52] <balunasj> so obviously anyone is free to comment or make suggestions
[17:14:02] <balunasj> it is not just for those on the projects
[17:14:21] <mojavelinux> do you want to start with the JSF 2.1 stuff?
[17:14:26] <balunasj> I will try to have agendas for the meetings posted, and we'll try to stick to them, but we are not bound to them.
[17:14:49] <balunasj> yeah lets start with JSF 2.1, but we should set a limit because we call all talk for hours on it
[17:14:53] <mojavelinux> Both the Seam devs and RichFaces devs have put together "wishlists" as you can see on the agenda page
[17:15:46] <mojavelinux> a point that is relevant for this meeting is that if the RichFaces team sees something on the Seam wishlist that you think could be fleshed out as a RichFaces component...that we can then work to standardize
[17:15:54] <mojavelinux> then we should move forward with that
[17:16:50] <mojavelinux> like the component referencing mechanism and subtree or cross-component validation
[17:16:56] <mojavelinux> I realize we have some solutions for these already
[17:17:12] <balunasj> There are also some items that nbelaevski has put into the spec issue tracker
[17:17:15] <mojavelinux> the idea would be to work them up to something we are ready to say "this is worth standardizing"
[17:17:16] <lincolnthree> this is the perfect time for such discussion, since we are just getting started with the Faces module in Seam 3 - aka. don't hold back
[17:17:37] <mojavelinux> XSD for Facelets is another one I really want to see
[17:17:51] <mojavelinux> we can demonstrate that this stuff works
[17:18:24] <mojavelinux> and also get the mindshare like we did with a4j:support -> f:ajax RichFaces got a lot of deserved credit for that
[17:18:41] <balunasj> there are some issues that were first discussed at jsfsummit
[17:18:46] <balunasj> and the moved forward
[17:18:53] <mojavelinux> meaning, you read articles and it says "f:ajax is like the a4j:support tag"
[17:18:54] <alexsmirnov> mojavelinux: out task for our CDK tool is generating XSD for taglibs too, so RichFaces could easely provide taglib schema.
[17:18:59] <balunasj> like queue management
[17:19:08] <mojavelinux> alexsmirnov, great!
[17:19:41] <mojavelinux> alexsmirnov, I'd like to be able to demonstrate how powerful it would be to have code completion of tags from XSD schema in regular XML editors (no special tooling)
[17:19:58] <mojavelinux> makes it easier for tooling too, then tooling focuses on the component previews (visual editor aspect)
[17:20:12] <balunasj> mojavelinux: exactly
[17:20:29] <balunasj> mojavelinux: is there a history of why XSD was not used already?
[17:20:32] <balunasj> alexsmirnov: ^
[17:20:45] <mojavelinux> balunasj, I'm speaking french or something
[17:20:48] <alexsmirnov> I work closely with Dennis from Jboss tools team; they able to read taglib information from schema.
[17:21:08] *** lincolnbaxter has joined #richfaces
[17:21:35] <mojavelinux> alexsmirnov, balunasj XSD is the most expressive language we have for describing XML...so it makes tons of sense to use it
[17:21:46] <alexsmirnov> balunasj: JSF has been started as JSP 1.2 taglib; facelets came late.
[17:22:14] <mojavelinux> alexsmirnov, yeah, that's the real reason...legacy...if there is one thing Facelets did more than anything else
[17:22:26] <balunasj> alexsmirnov: ok, was it discussed too late in the cycle to get into 2.0?
[17:22:29] <balunasj> edburns: ^
[17:22:31] <mojavelinux> alexsmirnov, was to make us respect XML
[17:23:00] <lincolnthree> it also helped truly separate the view logic from the model
[17:23:07] <lincolnthree> but
[17:23:10] <lincolnthree> thats a tangent
[17:23:55] <mojavelinux> lincolnthree, yeah, definitely lots of other good stuff...but in this context...
[17:23:57] <edburns> The facelet taglib XSD is a part of JSF 2.0, but you certainly know that so there must be something else you're asking about.
[17:24:06] <edburns> I'm glad to hear about automated XSD generation too.
[17:24:29] <mojavelinux> I think I know how to get my idea across
[17:24:34] <mojavelinux> you create a page /home.xml
[17:24:36] <mojavelinux> sorry
[17:24:44] <mojavelinux> page /home.xhtml
[17:24:54] <mojavelinux> now you want to put XML in that document
[17:25:09] <mojavelinux> you start with namespaces and reference XSD schema documents
[17:25:14] <mojavelinux> now you get tag completion
[17:25:23] <mojavelinux> <f:view [hit spacebar]
[17:25:51] <mojavelinux> I'd get tag completion in emacs, vim, jedit, gedit, XMLspy, ....
[17:26:09] <mojavelinux> <rich: [hit spacebar]
[17:26:21] <mojavelinux> no need for NetBeans or Eclipse at this point in the game
[17:27:24] <mojavelinux> so it would be excellent if RichFaces provided the XSD schemas for jsf/core and jsf/html on top of the ones for RichFaces
[17:27:36] <balunasj> mojavelinux: I get what you are saying, I don't think anyone disagrees
[17:27:42] <balunasj> mojavelinux: we are working towards that
[17:27:48] <mojavelinux> balunasj, awesome
[17:27:58] <balunasj> mojavelinux: but what is your goal for JSF 2.1 with this?
[17:28:07] *** jdlee has joined #richfaces
[17:28:15] <mojavelinux> balunasj, that they end up in jsf-impl.jar
[17:28:21] <balunasj> mojavelinux: we were going to do this anyway to make JBoss tools integration easier
[17:28:36] <balunasj> mojavelinux: you want RF XSD in jsf-impl.jar?
[17:29:17] <mojavelinux> balunasj, no, I want the standard tag libraries XSD in RichFaces (if Mojarra isn't going to provide it) and est a culture in the JSF vendors to provide XSDs for all component libraries
[17:29:49] *** lincolnbaxter has quit IRC
[17:29:55] *** lincolnbaxter has joined #richfaces
[17:30:24] <balunasj> mojavelinux: so beyond just the facelets XSD
[17:30:24] <mojavelinux> but where the XSD schemas for jsf/core and jsf/html belong is in the JSF implementation JARs...so that would be JSF 2.next
[17:30:48] <mojavelinux> balunasj, I realize that this request sounds simple...but clearly not simple enough given that we haven't gotten there yet
[17:31:21] <mojavelinux> balunasj, the other major hole in the JSF picture (from the perspective of developers) is cross-field validation
[17:31:30] <balunasj> mojavelinux: edburns said above that the facelets XSD is there, but you are talking specifically about jsf/core jsf/html
[17:32:43] <balunasj> or a standard for including these for components libs?  I guess what I'm missing the context.  This request is just to get XSD for jsf/core and jsf/html in the impl?
[17:33:17] <mojavelinux> balunasj, that's the ultimate goal, yes...but given that I'm getting tired of this argument, I'm ready to find them in richfaces-*.jar
[17:33:19] <lincolnbaxter> Yes. Having xsds for the component libraries themselves. Requiring facelets to be xml, not xhtml
[17:33:38] <mojavelinux> balunasj, then, what I really, really wanted for JSF 2.0 in this topic
[17:33:45] <mojavelinux> is that we use .view.xml as the extension
[17:33:53] <mojavelinux> because I disagree with .xhtml as the extension
[17:34:09] <mojavelinux> but I realize that there was a mindshare there already, so these things take time to play out
[17:34:10] <alexsmirnov> mojavelinux: JSF RI uses tool similar to CDK that generates all taglibs and Html* components. We can take its configuration ( that uses the similar faces-config with extension as CDK does ) to generate core schemas, or anybody can append XSD-generator to Mojarra tool.
[17:34:27] <balunasj> mojavelinux: lincolnthree : have you created spec issues for the above items ( I have not reviewed the seam framwork page in a while ).?
[17:35:28] <mojavelinux> balunasj, I have to check...I just realized that there might not be (it was a mailinglist thread)
[17:35:56] <lincolnbaxter> I know we discussed it on the list, not sure of issues
[17:36:05] <mojavelinux> balunasj, 490, filed by me https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=490
[17:37:15] <balunasj> lets hold off one the xml file and cross field validation for a min
[17:37:16] <mojavelinux> alexsmirnov, great
[17:37:42] <balunasj> alexsmirnov: nbelaevski : you guys had some thoughts as well on this
[17:37:49] <balunasj> we talked about queue updates
[17:38:06] <balunasj> and some issues that are not as cool, but are needed like
[17:38:07] <balunasj> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=734
[17:38:45] <balunasj> I think for the first meeting we get the items to break down and discuss, but not dig in
[17:38:49] * edburns looks at 734
[17:39:13] <balunasj> in other words it is already 20 min left in scheduled time
[17:39:45] <balunasj> nbelaevski: do you have that link to the other spec issues?
[17:39:57] <nbelaevski> http://goo.gl/FvQz
[17:40:22] <balunasj> nbelaevski: thanks
[17:40:53] <balunasj> one of our upcoming tasks is to review our queue impl and discuss updates or suggestions for JSF 2.1
[17:41:02] <balunasj> I don't believe we can completed that yet
[17:41:10] <alexsmirnov> I have question to Seam guys: are you going to support portlets ? Last year I had talk with Gavin at JavaOne; He declined to support portlets at all.
[17:41:56] <mojavelinux> alexsmirnov, we are taking a fresh start...and after talking to wesleyhales at DevNexus, it's clear that we have been downright dismissive of our own portlet initiatives
[17:42:06] <mojavelinux> alexsmirnov, so I would say, it's back on the table
[17:42:52] <balunasj> mojavelinux: so you guys would like to see portlet support, but it is not priority one - correct?
[17:42:54] <mojavelinux> and important aspect of that is to get lincolnthree to understand what considerations need to be taken for portlets
[17:43:19] <balunasj> not many people better to talk to about that than alexsmirnov
[17:43:44] <mojavelinux> balunasj, I'm open to being convinced how important it is...I've been at companies where we probably could have used them...but the portlet bridge was not where it is today when we looked at it
[17:44:05] <mojavelinux> wesleyhales certainly talks about it, so you have at least another voice
[17:44:09] * prabhat notes if it matters, I would vote to see full Richfaces and Seam support in portal environemnt
[17:44:57] <balunasj> we are certianly taking it into consideration and making sure we don't do things that exclude the effort.
[17:45:15] <balunasj> Before we get ALPHA2 out though it is not priority
[17:45:32] <alexsmirnov> GateIn already uses RichFaces with bridge for couple of administrative applications, similar to Jboss AS console.
[17:45:42] <mojavelinux> balunasj, basically, I'd just like to see a change in attitude (from us), so that's perhaps what we establish today
[17:46:42] <balunasj> mojavelinux: I'm not sure what we can do differently ;-)
[17:46:47] <wesleyhales> mojavelinux balunasj +1
[17:47:02] <wesleyhales> just joined in so trying to catch up
[17:47:15] <balunasj> mojavelinux: We need to get ALPHA2 out asap - then we'll have some time to focus on integration points
[17:47:26] <balunasj> like Portal, but also other component libraries
[17:47:58] <balunasj> I have a feeling some of the same rules that make portlets interoperate will apply to comp. libs too
[17:48:56] <mojavelinux> balunasj, by us, I meant certain (former) Seam developers
[17:49:02] <balunasj> alexsmirnov: wesleyhales : have you guys ever written out an FAQ or top 10 things not to do to help with portlet support?
[17:49:11] <balunasj> mojavelinux: ic
[17:49:16] <mojavelinux> balunasj, but not anyone present today
[17:49:32] *** lightguard_jp has quit IRC
[17:49:33] <wesleyhales> balunasj: good idea
[17:49:36] <mojavelinux> balunasj, great suggestion...or even just "how not to leave porlets in the dust"
[17:49:47] <wesleyhales> balunasj: we need to do that, now that we are all communicating better
[17:49:52] <mojavelinux> balunasj, "how to play nicely together in the sandbox"
[17:49:52] *** lightguard_jp has joined #richfaces
[17:50:01] <balunasj> right
[17:50:07] <mojavelinux> balunasj, good start
[17:50:16] <wesleyhales> noted
[17:50:19] <mojavelinux> handshake
[17:50:27] <balunasj> I would image a similar thing could come out of comp lib integration work.
[17:50:38] <balunasj> I'm guessing first time out it won't be easy
[17:50:42] <alexsmirnov> I like the idea. I'll write out it somwhere on Jboss wiki.
[17:51:03] <balunasj> alexsmirnov: great, perhaps you and wesleyhales could work together on it.
[17:51:20] <mojavelinux> so another topic is: where do the responsibility of components fall
[17:51:36] <mojavelinux> in an e-mail, I stated that we don't want to be in the business of creating visual components
[17:51:47] <mojavelinux> but functional components, there is a gray area
[17:51:56] <balunasj> mojavelinux: it might be better to start with where integration points were in Seam 2 and RF 3
[17:51:57] <mojavelinux> for instance, I'm strongly in favor of having UIViewAction in Seam faces
[17:52:05] <balunasj> so we have a base of understanding
[17:52:33] <balunasj> and then discuss some of the concerns and plans for Seam 3 and RF4
[17:52:39] <mojavelinux> balunasj, were there integration points?
[17:52:47] <balunasj> nbelaevski: alexsmirnov : could you guys outline some of these
[17:53:12] <balunasj> they are more familiar with the details of RF 3 and Seam 2 items like this
[17:53:24] <mojavelinux> to me, integration implies a two way street
[17:54:09] <mojavelinux> I mostly saw it as RF did work and Seam devs ignored it
[17:54:15] <mojavelinux> again, change in attitude
[17:54:39] <mojavelinux> (I'm not bitter, I swear, just optimistic about the future)
[17:55:18] <lincolnbaxter> :)
[17:55:31] <mojavelinux> they way I see the future is, a request comes in to a router
[17:55:53] <alexsmirnov> mojavelinux:  One more thing to integrate: we extracted all RF test libraries as separate project, so they can be used by Seam too.
[17:55:54] <mojavelinux> and we say "you know, that would be perfect for RichFaces" and so we mindfully sort these things
[17:56:03] <mojavelinux> alexsmirnov, yes!
[17:56:25] <mojavelinux> alexsmirnov, and that we are hoping to push into the newly formed JBoss testing group (Arquillian, JSFUnit, etc)
[17:56:54] <mojavelinux> OMG, it looks like we actually have strategy
[17:56:57] <alexsmirnov> Hick recentli written the article about that http://community.jboss.org/wiki/MockObjectsforTestDrivenJSFDevelopmentorgjbosstest-jsfjsf-mockproject
[17:57:25] <mojavelinux> alexsmirnov, I've got that one starred for reading tonight...so valuable
[17:57:27] <alexsmirnov> Nick :-)
[17:57:52] <balunasj> nbelaevski did a good job of explaining it
[17:58:34] <balunasj> it is one of our goals to make that its own project ( like Arquillian ), but that is another thing that might not happen until A2 is out
[17:59:05] <mojavelinux> take your time, just as long as the goal is set...we're on the right path
[17:59:12] <mojavelinux> so we should talk about these: http://docs.jboss.org/seam/2.2.0.GA/reference/en-US/html_single/#controls
[17:59:16] <balunasj> yes - it is a goal
[17:59:23] <mojavelinux> I can sum this up really quickly
[17:59:31] <mojavelinux> when we need a UI component
[17:59:38] <mojavelinux> we need to be smart about where it goes
[18:00:12] <mojavelinux> Let's cite some examples
[18:00:17] <mojavelinux> conversation controls
[18:00:24] <mojavelinux> RichFaces or Seam?
[18:00:38] <mojavelinux> Or a new component library under RichFaces that is functional (not visual)
[18:00:54] <balunasj> Ok
[18:01:01] <balunasj> here is my biggest concern with that
[18:01:07] <balunasj> dependencies
[18:01:43] <alexsmirnov> for JSF 2.0, they could be moved to RichFaces but use JSF flash or Seam conversations depends of configuration.
[18:02:12] <balunasj> I am concerned that if we start moving components to Seam JSF lib that all of sudden RF users need to start using a % of Seam modules
[18:02:19] <balunasj> that they might not want to use
[18:02:38] <mojavelinux> balunasj, yes, that is the important aspect of this discussion
[18:02:49] <mojavelinux> just to clarify...seam-faces will have this dependency tree
[18:02:51] <alexsmirnov> We already have some functional components because some developers doesn't like to have whole seam stuff just for one function.
[18:02:58] <balunasj> Pete at the time thought that the Seam JSF module would be free of dependencies.
[18:03:04] <mojavelinux> seam-faces -> seam-i18n
[18:03:05] <mojavelinux> that's it
[18:03:10] <mojavelinux> at least planned for now
[18:03:25] <balunasj> so a user could integration just seam-faces and not other parts.
[18:03:38] <mojavelinux> we just can't live w/o i18n support because it just doesn't exist in Java EE
[18:03:44] <mojavelinux> yes
[18:04:23] <balunasj> mojavelinux: that would be ok I think, obviously with Seam 2 it is more of the whole pie or nothing
[18:04:37] <mojavelinux> here is how I see this playing out
[18:04:49] <mojavelinux> I feel very strongly that UIViewAction metadata component belongs in Seam
[18:05:20] <mojavelinux> because that is a big part of what Seam is offering...greater control over requests and navigation...that's the extension we have to offer
[18:05:39] <mojavelinux> what I don't want is stuff like formatted text, format date, etc
[18:05:45] <mojavelinux> because that is part of "richness"
[18:05:48] <alexsmirnov> mojavelinux:  really, that is belong JSF 2.1 and page "execute" phase - have you read JSF-EG discussion ?
[18:06:01] <mojavelinux> file upload, another example of what doesn't belong in Seam
[18:06:27] <mojavelinux> alexsmirnov, yes, UIViewAction is our proposal for what should be in JSF
[18:06:37] <mojavelinux> alexsmirnov, so we are hosting the prototype
[18:06:54] <mojavelinux> alexsmirnov, but we also having things like UISecureView which will use Seam Security to lock down a page
[18:07:11] <balunasj> I agree UIViewAction belongs in JSF, but also that someone needs to prototype the solution
[18:07:41] <mojavelinux> s:span, s:div, s:fragment...all inappropriate for Seam...and you guys can pick them up or we just drop them (in favor of using composite components or something)
[18:08:08] <balunasj> mojavelinux: your break up of the component seem good.  I think it would be more of a problem if we started to move func. from RF
[18:08:10] <mojavelinux> something like convertEntity, probably a Seam thing
[18:08:12] <balunasj> into Seam
[18:08:16] <mojavelinux> because it requires coordination w/ persistence context
[18:08:20] <balunasj> sure
[18:08:29] <mojavelinux> balunasj, right, we are mostly giving you thing
[18:08:30] <balunasj> Then there is talk of validation components
[18:08:32] <mojavelinux> things
[18:08:41] <mojavelinux> balunasj, but more import, we *stop duplicating your work*
[18:08:42] <alexsmirnov> mojavelinux: From RichFaces, bean tree validation more likely belong to Seam. JSF supports per-field validation only, but validation of entire object requires more complicated actions.
[18:08:52] <balunasj> that may need to wait for next week.
[18:08:57] <balunasj> lets give it another 10 min or so
[18:08:59] <mojavelinux> alexsmirnov, yes, that is something we'd like to bring back into Seam
[18:09:43] <mojavelinux> alexsmirnov, and btw, this problem is so absolutely critical to solve because the community is pretty disappointed that the x-field validation story is still the same today...meaning there is no story
[18:09:57] <balunasj> would seem be managing the complete client side validation, ajax requests, etc... or just the server side parts?
[18:10:05] <mojavelinux> alexsmirnov, the truth is, the problem is hard...so I'm excited to work together to solve it
[18:10:24] <balunasj> I think there would be a mix
[18:10:46] <mojavelinux> balunasj, that is a hard question to answer...
[18:10:54] <balunasj> between seam and RF.
[18:11:14] <balunasj> either way I think that is an integration point
[18:11:16] <balunasj> to discuss
[18:11:44] <mojavelinux> balunasj, I think you can start with in RichFaces...because it is going to tie in closely to Ajax and behaviors
[18:11:58] <balunasj> alexsmirnov: in RF 3 there were other integration points between seam and RF right.  Can't think of it right now.
[18:12:02] <alexsmirnov> mojavelinux: It partially solved. RichFaces can "clone" object and validate it without actual model updates. I use explicit Cloneable marks, but Seam can take a care for such substitution in transparent way.
[18:12:11] <balunasj> we should get that one the table so we can discuss later
[18:12:38] <mojavelinux> balunasj, yes
[18:13:10] <mojavelinux> alexsmirnov, yep, that is certainly something to keep researching
[18:13:58] <mojavelinux> alexsmirnov, working on the Seam side of things
[18:14:49] <balunasj> ok guys - I think we should probably break. and pick this up at the next meeing
[18:14:53] <balunasj> but before that
[18:14:55] <mojavelinux> In summary of the first integration discussion
[18:14:57] <mojavelinux> I would say:
[18:15:20] <balunasj> does anyone know a time frame for JSF 2.1?  i.e. do we need to ramp up these meeting and have them weekly?
[18:15:21] <mojavelinux> a) we need to avoid having conflicting components (Seam and RichFaces both have file upload for example)
[18:15:43] <mojavelinux> b) we need to treat this as a two way street, which means a better, more open attitude from the Seam team
[18:16:57] <balunasj> agreed
[18:16:58] <mojavelinux> as for (a), RF might want to consider having more fine-grained library sets...just to make them more consumable
[18:17:16] <edburns> balunasj: I'm working very hard on getting a timeframe for that.
[18:17:32] <balunasj> you mean breaking into modules such as input, output, table, tree, etc...?
[18:17:48] *** edburns is now known as edburns_away
[18:17:51] <balunasj> edburns: thanks - just wanted to see where we were with that
[18:18:08] <mojavelinux> for instance, think about the fact that developers might want upload/download w/o visual components
[18:18:23] <mojavelinux> balunasj, not that fine-grained
[18:18:29] <balunasj> ok good
[18:18:38] <mojavelinux> balunasj, functional vs visual vs form-support (conversions)
[18:18:57] <mojavelinux> balunasj, broad usage categories
[18:19:00] <balunasj> most non-visual component are more of a4j, but there is some overlap
[18:19:17] <alexsmirnov> mojavelinux: RF was always developed as set of small projects that can be used separately. We combine that as whole library as last stage of build.
[18:19:32] <mojavelinux> balunasj, I'd even say consider a rename of that prefix...a4j really doesn't fit a lot of things you have
[18:19:45] <balunasj> for 4.0 we will support custom builds that can be packaged as needed.
[18:19:56] <mojavelinux> balunasj, excellent...
[18:20:13] <balunasj> mojavelinux: We'll have to discuss renaming a4j
[18:20:40] <mojavelinux> balunasj, you could always leave the a4j grouping, but introduce other cross sections of your inventory
[18:21:03] <balunasj> a4j already has a meaning to our users
[18:21:21] <balunasj> they known those as the core components
[18:21:35] <balunasj> I'd be interested in your ideas, but perhaps in an email?
[18:21:36] <mojavelinux> balunasj, yes, but the Seam developers (that don't use RichFaces) don't
[18:21:40] <mojavelinux> balunasj, yep
[18:21:58] <lincolnbaxter> I think a4j is appropriate for the functionality
[18:22:14] <balunasj> lets break for now - I'll create some minutes ( perhaps we can pass around that responsibility )
[18:22:26] <balunasj> lincolnbaxter: agree
[18:22:58] <balunasj> I could see perhaps creating a separate tag, but "rich:" is going no where :-)
[18:23:36] <mojavelinux> balunasj, yep, that's a wrap
[18:23:49] <balunasj> ok all thanks
[18:23:52] <lincolnbaxter> Holla'
[18:23:53] <balunasj> it was a good meeting
[18:24:01] <mojavelinux> balunasj, I'm just saying, leave rich and a4j groups as is, but introduce new groupings that may use some of the same components, with a new focus
[18:25:00] <balunasj> mojavelinux: interesting...I'll need to think on it
[18:27:24] <alexsmirnov> thanks all, I have to run now.