balunasj
:
ok guys I think we can get started - I just needed to wrap something up
[
10:04am
]
balunasj
:
So if you take a look at the agenda the first thing I wanted to talk about it the CDK status for ALPHA1
[
10:04am
]
balunasj
:
alexsmirnov: thoughts?
[
10:05am
]
Konstantin joined the chat room.
[
10:07am
]
alexsmirnov
:
Unfortunately, there are a lot of tasks remain. But I got visible progress in development last days.
[
10:08am
]
balunasj
:
alexsmirnov: ok that is good & bad then
[
10:09am
]
balunasj
:
alexsmirnov: with a couple of guys helping out it should help - correct?
[
10:09am
]
balunasj
:
nbelaevski: how is the template compiler work going?
[
10:10am
]
nbelaevski
:
balunasj: initial draft is ready, i'm setting build for it now - it's pretty complex
[
10:10am
]
balunasj
:
nbelaevski: who was going to work on that - https://jira.jboss.org/jira/browse/RFPL-62
[
10:10am
]
balunasj
:
can you or the person working on it assign the jira?
[
10:10am
]
nbelaevski
:
balunasj: that's it
[
10:11am
]
nbelaevski
:
sure, assigned
[
10:11am
]
balunasj
:
nbelaevski: I understand, keep me informed on how it is going and when there is something to look at.
[
10:11am
]
balunasj
:
nbelaevski: the EL compiler is not going to make it for this release - right
[
10:11am
]
nbelaevski
:
it's not very cute - templates are inline strings for now
[
10:11am
]
nbelaevski
:
balunasj: i've created the simples one to suit our needs for now
[
10:12am
]
nbelaevski
:
it understands #{clientid} and #{component.attributes['name']} - this should be enough for now
[
10:12am
]
balunasj
:
nbelaevski: ok that is probably best for now anyway - get a base together that we can build from.
[
10:12am
]
balunasj
:
nbelaevski: ok
[
10:12am
]
nbelaevski
:
balunasj: i'm keeping this in mind together with three components planned for me this week
[
10:13am
]
balunasj
:
alexsmirnov: what part are you working on right now - the annotation processor?
[
10:14am
]
balunasj
:
nbelaevski: yup - I know it is getting tight
[
10:14am
]
nbelaevski
:
balunasj: schema took lot of time
[
10:14am
]
alexsmirnov
:
With CDK, I'm going to finish annotation processing. I wrote out syntax of some annotations that are used by CDK and will put there all of them. http://www.jboss.org/community/wiki/RichFacesCDKannotations
[
10:14am
]
balunasj
:
nbelaevski: thankfully we don't have much to do on 3.3.2.CR1 right now and hopefully the assistance from that team will help.
[
10:15am
]
alexsmirnov
:
There is task related to that https://jira.jboss.org/jira/browse/RFPL-65
[
10:15am
]
balunasj
:
alexsmirnov: ok good - please update the wiki's as possible with the latest info
[
10:15am
]
balunasj
:
alexsmirnov: ic - I was looking here https://jira.jboss.org/jira/browse/RFPL-44
[
10:15am
]
nbelaevski
:
balunasj: we're not finished with a4j:status reqs. for now - and that depends on Ilya only
[
10:16am
]
nbelaevski
:
balunasj: other components are mostly clear...
[
10:16am
]
ilya_shaikovsky
:
I'm finished with proposal
[
10:16am
]
ilya_shaikovsky
:
and sent a letter today
[
10:16am
]
ilya_shaikovsky
:
we done it yesterday with Alex
[
10:16am
]
balunasj
:
ilya_shaikovsky: I have not seen the letter yet - but we need to review the wiki page once we finish cdk
[
10:17am
]
balunasj
:
alexsmirnov: nbelaevski : when do you think CDK will be ready for ALPHA1?
[
10:18am
]
nbelaevski
:
balunasj: I expect compiler to be freezed today in ~4-6hours
[
10:18am
]
balunasj
:
we had discussed a deadline of early next week for the CDK so that we had time to complete the components before end of August.
[
10:18am
]
balunasj
:
nbelaevski: wow- great
[
10:18am
]
alexsmirnov
:
We discussed an idea to remove all group assigments from status/queue and move them to a separate tag. That will simplify our components and shares group assigment logic between components.
[
10:18am
]
balunasj
:
I'm assuming we'll need integration and dev-testing time for the cdk as well.
[
10:19am
]
balunasj
:
alexsmirnov: lets finish up the cdk talk before we move on to the component talk
[
10:19am
]
balunasj
:
alexsmirnov: when do you think you'll finish up the CDK work for ALPHA1?
[
10:21am
]
alexsmirnov
:
That seems about one week ( 5 working days ) to get components generated by the CDK.
[
10:21am
]
balunasj
:
nbelaevski: is anyone else going to be helping with the CDK tasks  - right now I see Andrey working on the EL compiler, and you with the template compiler, and schema - is alex handling the rest?
[
10:21am
]
nbelaevski
:
balunasj: yes
[
10:21am
]
nbelaevski
:
Alex does the rest. and the result of Andrey's work won't be included into A1
[
10:21am
]
balunasj
:
nbelaevski: right
[
10:22am
]
nbelaevski
:
balunasj: one more thing to mention - template compiler has no unit tests at all
[
10:22am
]
balunasj
:
alexsmirnov: so you think by next tuesday/wed we'll have a CDK that is ALPHA1 ready?
[
10:23am
]
nbelaevski
:
balunasj: I'll add them in the future - that's all because we need something working for components now
[
10:23am
]
balunasj
:
alexsmirnov: We'll need that for the rest of the release too so it is important.
[
10:23am
]
alexsmirnov
:
balunasj: Yes, I believe that. nick: no tests is bad
[
10:24am
]
balunasj
:
nbelaevski: Agreed we'll need to add them - we just can't let a whole bunch of test backlog pile up.
[
10:24am
]
alexsmirnov
:
For my parts, most of code is covered by unit tests and has javadoc comments. That is why progress seems slowly sometime
[
10:24am
]
nbelaevski
:
alexsmirnov: agree. what shall we do now?
[
10:26am
]
nbelaevski
:
alexsmirnov: balunasj: I mean force tests or continue with components?
[
10:27am
]
balunasj
:
nbelaevski: I think we can have some middle ground for now - add some base unit tests, and perhaps comments for others that are needed, and then start on components.  We'll need to revisit this though right after A1.  Y
[
10:27am
]
balunasj
:
you may also want to create a jira for this task - I think that would be a RF jira btw
[
10:28am
]
balunasj
:
nbelaevski: do you think that will work?
[
10:28am
]
alexsmirnov
:
I use tests for development and debug purposes, therefore they are necessary for me. If you believe to manual testing, switch to components.
[
10:28am
]
nbelaevski
:
balunasj: I need one or two days more to do it - who will do components then?
[
10:29am
]
nbelaevski
:
balunasj: that's my concern
[
10:30am
]
balunasj
:
nbelaevski: you will need 1-2 days to add some base tests?  Perhaps someone else from the team can add the tests?
[
10:30am
]
balunasj
:
nbelaevski: Perhaps Andrey since EL compiler won't make it for ALPHA1
[
10:30am
]
balunasj
:
nbelaevski: might be good to have a second set of eyes on the work anyway
[
10:30am
]
nbelaevski
:
balunasj: ok, agree
[
10:31am
]
balunasj
:
ok good
[
10:31am
]
nbelaevski
:
balunasj: btw, why tests shuld be in RF?
[
10:31am
]
nbelaevski
:
balunasj: or I haven't got you right?
[
10:31am
]
balunasj
:
speaking of jira - I think most of the jira's in https://jira.jboss.org/jira/browse/RFPL-44 are really RF jiras
[
10:32am
]
balunasj
:
These are items that are pretty specific for the release and represent code that is being committed and
[
10:32am
]
nbelaevski
:
got you
[
10:32am
]
balunasj
:
unit tests tasks also fall into that category as well.
[
10:33am
]
balunasj
:
For example we would want RFPL for "Design Refactor new CDK"
[
10:33am
]
balunasj
:
but RF for the break downs in https://jira.jboss.org/jira/browse/RFPL-44
[
10:34am
]
balunasj
:
That is mainly because that break down is at a good detail level for RF
[
10:34am
]
balunasj
:
not to the tiny details, but larger units of work.
[
10:34am
]
balunasj
:
If one of these tasks needed to be broken down into micro tasks that is when RFPL would come back in.
[
10:35am
]
alexsmirnov
:
Ok.
[
10:35am
]
balunasj
:
ok lets move on to the component review
[
10:35am
]
alexsmirnov
:
I can move them into corresponding RF task.
[
10:35am
]
balunasj
:
alexsmirnov: that would be good thanks
[
10:36am
]
balunasj
:
http://www.jboss.org/community/wiki/A4jCoreComponentsRequirements
[
10:36am
]
balunasj
:
I 100% agree and support the idea of moving the queue and status attributes out of the action components.
[
10:37am
]
ilya_shaikovsky
:
?
[
10:37am
]
ilya_shaikovsky
:
I thought about requiestDelay and ignoreDupResponce
[
10:38am
]
ilya_shaikovsky
:
only.. you could still define queue and status for separate component. but more convinient ways proposed
[
10:40am
]
balunasj
:
ilya_shaikovsky: say the last sentence a different way please - not sure I'm understanding
[
10:40am
]
ilya_shaikovsky
:
your comment was "IgnoreDupResponse and RequestDelay can be limited to queue settings"
[
10:40am
]
ilya_shaikovsky
:
I'm agreed completelly and moved with this proposal
[
10:40am
]
ilya_shaikovsky
:
but queue and status itself could be added for separate component
[
10:41am
]
ilya_shaikovsky
:
by using attributes
[
10:41am
]
ilya_shaikovsky
:
dohh.. seems I misunderstand you
[
10:41am
]
ilya_shaikovsky
:
sorry
[
10:41am
]
ilya_shaikovsky
:
just got it
[
10:41am
]
ilya_shaikovsky
:
talking about the same
[
10:41am
]
balunasj
:
ilya_shaikovsky: np lets make sure we are on the same page.
[
10:42am
]
balunasj
:
ilya_shaikovsky: A component should be able to define what queue to use, but all of the queue related setting should belong to queue itself no set by the component
[
10:42am
]
balunasj
:
something like:
[
10:42am
]
ilya_shaikovsky
:
yup.
[
10:42am
]
balunasj
:
<a4j:commandButton ... queue="foo"\>
[
10:43am
]
balunasj
:
There is another way to look at this, which is to treat it as a behavior - although I'm not 100% convinced of this
[
10:43am
]
balunasj
:
<a4j:commandButton ...>
[
10:44am
]
balunasj
:
  <a4j:useQueue queueid="foo"/>
[
10:44am
]
balunasj
:
not sure I like that though
[
10:44am
]
balunasj
:
Another option would be
[
10:45am
]
balunasj
:
<a4j:commandButton id="bar"/>
[
10:45am
]
balunasj
:
<a4j:queue for="bar" />
[
10:45am
]
ilya_shaikovsky
:
I think  last wrong
[
10:45am
]
balunasj
:
This really represents the three ways to associate one component with another.
[
10:45am
]
ilya_shaikovsky
:
because if you need to point many components - it will be long list of them
[
10:46am
]
balunasj
:
I think when we are considering things like queue and status etc.... we can think of which of these make sense.
[
10:46am
]
ilya_shaikovsky
:
first seems the same as second but the definition itself - easier
[
10:46am
]
ilya_shaikovsky
:
and results the same.. not sure that we need tag for behavior
[
10:47am
]
balunasj
:
ilya_shaikovsky: We would use the extra tag to make the commandButton attributes cleaner
[
10:47am
]
balunasj
:
ilya_shaikovsky: but I also agree with you that the first is probably the best option for queue
[
10:48am
]
balunasj
:
nbelaevski: alexsmirnov others: thoughts?
[
10:48am
]
ilya_shaikovsky
:
and b.t.w Jay I think you saw last 10. point .. It's connected with queue and status definitions close
[
10:49am
]
nbelaevski
:
balunasj: that's something for me - need some time to think
[
10:49am
]
alexsmirnov
:
I prefer to simplest way.
[
10:50am
]
balunasj
:
alexsmirnov: assuming you mean the first option
[
10:50am
]
balunasj
:
nbelaevski: understood - I'm not 100% on any of them
[
10:50am
]
alexsmirnov
:
I meant, do not overload components by attributes, bur separate group assigments to tag and use that for all alike tasks.
[
10:51am
]
nbelaevski
:
balunasj: I don't think it's a good idea - queue tag serves as pipe to execute all requests
[
10:51am
]
nbelaevski
:
what if you want to set different values for timeout?
[
10:51am
]
nbelaevski
:
but still use the same queue
[
10:52am
]
balunasj
:
nbelaevski: I think there would be limited use cases that but can think of one or two
[
10:52am
]
balunasj
:
nbelaevski: the best approach for that I think would be
[
10:52am
]
balunasj
:
<a4j:commandButton ...>
[
10:53am
]
balunasj
:
  <a4j:useQueue queueid="foo" timeout="500"/>
[
10:53am
]
balunasj
:
Again I don't like the name
[
10:53am
]
balunasj
:
"useQueue" - it is just a place holder
[
10:53am
]
balunasj
:
but what this lets you do is add functionality to any action component
[
10:54am
]
balunasj
:
without cluttering all action components with attributes that only a few will use
[
10:54am
]
nbelaevski
:
I agree with such variant
[
10:54am
]
pmuir
:
<a:attachQueue />?
[
10:55am
]
balunasj
:
pmuir: I like the same
[
10:55am
]
balunasj
:
I like the name
[
10:55am
]
nbelaevski
:
or queueReference
[
10:55am
]
balunasj
:
or is this more of a behavior
[
10:55am
]
balunasj
:
queueBehavior
[
10:55am
]
balunasj
:
to follow JSF 2.0 naming
[
10:56am
]
balunasj
:
To really follow JSF 2.0 naming I think it would be "attachQueue" with the trailing "Behavior" dropped
[
10:56am
]
ilya_shaikovsky
:
and we will have attribute "queue", queue behavior and queue component?
[
10:56am
]
pmuir
:
in english there is a difference between {use,attach,reference}Queue and queue{Reference,Behavior}
[
10:56am
]
balunasj
:
like f:ajax with the "Behavior" dropped
[
10:57am
]
pmuir
:
as in one we are using a verb and a noun, the other two nouns
[
10:57am
]
balunasj
:
pmuir: agreed, and I think "attachQueue" is accurate
[
10:58am
]
balunasj
:
ilya_shaikovsky: queueId I believe
[
10:58am
]
ilya_shaikovsky
:
I mean all three things?
[
10:59am
]
balunasj
:
a4j:attachQueue ( as a behavior)
[
10:59am
]
balunasj
:
a4j:queue ( to define the actual queue )
[
11:00am
]
balunasj
:
attribute "queueId" for both
[
11:00am
]
ilya_shaikovsky
:
got it and seems sounds good..
[
11:00am
]
balunasj
:
for a4j:queue it defines the queue's name
[
11:00am
]
balunasj
:
for a4j:attachQueue it defines what queue to attach
[
11:00am
]
ilya_shaikovsky
:
espesially the point that we could not only reference component to queue but also pass redefined parameters
[
11:00am
]
balunasj
:
ilya_shaikovsky: ok great
[
11:01am
]
balunasj
:
ilya_shaikovsky: Yes I think that is the best reason for this behavior
[
11:01am
]
balunasj
:
ilya_shaikovsky: as nbelaevski was saying there may be times when you need to override
[
11:01am
]
alexsmirnov
:
I think 'queueId' is overloaded for a4j:queue. Let's compare "a4j:queue queueId=''" and 'a4j:queue id=''"
[
11:02am
]
balunasj
:
alexsmirnov: good point
[
11:02am
]
balunasj
:
so for a4j:queue it is just "id"
[
11:02am
]
balunasj
:
unless anyone can think of a good reason to have the component id different than the queue id
[
11:02am
]
balunasj
:
?
[
11:03am
]
alexsmirnov
:
I don't see any reason to have different names.
[
11:03am
]
balunasj
:
alexsmirnov: ok neither do I
[
11:04am
]
balunasj
:
so I know we are out of time, but lets figure out how we want to handle status
[
11:04am
]
balunasj
:
it is a similar problem
[
11:04am
]
balunasj
:
and may have a similar solution
[
11:04am
]
balunasj
:
option 1)
[
11:05am
]
balunasj
:
treat the same as queue above
[
11:05am
]
balunasj
:
users define a a4j:status one or more time on a page ( with unique IDs)
[
11:05am
]
balunasj
:
users then use a4j:attachStatus to action components
[
11:05am
]
balunasj
:
that wish to use this status for there requests
[
11:06am
]
balunasj
:
nbelaevski: you had said there could be complications using status as a behavior would this approach help?
[
11:06am
]
ilya_shaikovsky
:
but minor difference point we do not need to redefine any parameters there.. so this behavior tag not looks so usefull
[
11:07am
]
balunasj
:
Some some thing like this:
[
11:08am
]
balunasj
:
<a4j:commandButton ...>
[
11:08am
]
nbelaevski
:
balunasj: that's requires much handwork
[
11:08am
]
balunasj
:
  <a4j:attachStatus statusId="foo"...>
[
11:08am
]
ilya_shaikovsky
:
and about behavior.. status is ui component with DOM representation which corresponds to place in components tree.. so it not looks like behavior
[
11:08am
]
balunasj
:
    <a4j:param name="" value="" /> for overriding parameters
[
11:09am
]
balunasj
:
ilya_shaikovsky: right - that is why I'm proposing separating a4j:status (the ui component ) with a4j:attachStatus ( the behavior )
[
11:10am
]
balunasj
:
nbelaevski: what do you mean handwork?  Hardwork?
[
11:10am
]
nbelaevski
:
no, much typing
[
11:10am
]
balunasj
:
nbelaevski:  to implement in our code, or for users?
[
11:10am
]
nbelaevski
:
for users
[
11:11am
]
nbelaevski
:
imagine that for each support you'll have to type this
[
11:11am
]
balunasj
:
I'm certainly open for suggestions too - this is just one idea based on the queue talk
[
11:11am
]
ilya_shaikovsky
:
I'm talking not about how to redefine the params.. I mean that we have seems nothing to redefine there.. so separate tags behavior and component looks for me worse than just for-like attribute and actual ui-component there.
[
11:11am
]
nbelaevski
:
and support can be attached to each form field
[
11:11am
]
rruss joined the chat room.
[
11:12am
]
balunasj
:
So does it make more sense to use "for=""" in a status?
[
11:12am
]
ilya_shaikovsky
:
with defaults like we have in queue.. for global statuses
[
11:12am
]
ilya_shaikovsky
:
As I wtritten in wiki we talked about
[
11:12am
]
ilya_shaikovsky
:
common status for view
[
11:12am
]
ilya_shaikovsky
:
common status for form (maybe)
[
11:12am
]
ilya_shaikovsky
:
status defined explicitly on ajax components by statusId
[
11:13am
]
•
balunasj
 
looking again...
[
11:13am
]
ilya_shaikovsky
:
and bulk applying described in section 10.
[
11:16am
]
balunasj
:
hmmm I'm not sure - I don't completly understand the the example you posted there, but in general I like the idea of something like a "a4j:apply" component
[
11:16am
]
balunasj
:
I'll need to think on it more
[
11:17am
]
balunasj
:
ilya_shaikovsky: in your example what is the attribute and value for ?
[
11:17am
]
ilya_shaikovsky
:
we could attach status using apply or queue using apply.. attribute - which attribute we want to apply and value - with which value
[
11:18am
]
alexsmirnov
:
To compare different syntax, it makes sense to write out page snippets that uses each approach.
[
11:18am
]
ilya_shaikovsky
:
sure
[
11:18am
]
ilya_shaikovsky
:
I could update in a short time
[
11:18am
]
balunasj
:
alexsmirnov: agreed
[
11:19am
]
alexsmirnov
:
I agree with nick, using separate tags requires a lot of typing. It's also hard to reuse in composite components.
[
11:19am
]
balunasj
:
ilya_shaikovsky: So attribute is saying which attribute in the matching "forId" to update and value to update it with?
[
11:19am
]
ilya_shaikovsky
:
yup
[
11:20am
]
ilya_shaikovsky
:
so the component has wide possibilities.. not just queues and statuses definitions
[
11:20am
]
balunasj
:
ilya_shaikovsky: can we support wild cards for ID without a performance problem?
[
11:21am
]
ilya_shaikovsky
:
this is just a sample for initial discussion
[
11:21am
]
ilya_shaikovsky
:
should revise it for such points
[
11:21am
]
balunasj
:
This seems like a generic type of render time attribute manipulation - is that the idea?
[
11:21am
]
ilya_shaikovsky
:
if you think it looks good enough to continue
[
11:22am
]
ilya_shaikovsky
:
yes
[
11:23am
]
balunasj
:
ilya_shaikovsky: the idea of generic way to manipulate attributes is not bad, I just need to think of it more.  I
[
11:23am
]
balunasj
:
also don't think it really effects the ideas for status and queue - they need to be solved with/without this
[
11:25am
]
alexsmirnov
:
balunasj: The idea is fine, but it could be hard to implement... I just took a look in the JSD TagHandlers - some of them parses attributes in constructor, that could break an idea
[
11:26am
]
balunasj
:
alexsmirnov: I see, and good points for sure.
[
11:26am
]
balunasj
:
ilya_shaikovsky: can you write up the different approaches we discussed above and expand your thoughts on the a4j:apply
[
11:26am
]
balunasj
:
send an email to the design forums when finished, and we'll discuss.
[
11:26am
]
ilya_shaikovsky
:
sure.. I'll continue this section
[
11:27am
]
balunasj
:
I need to get going, but this was a good talk and we'll need more like it
[
11:27am
]
balunasj
:
thanks all
[
11:27am
]
ilya_shaikovsky
:
and thanks you