10:43am
]
alexsmirnov
:
Nick ( and others ). On yesterday JSF EG meeting we decided to start "Rev A" specification update that should be released at mid February. Although it is not going to make any significant changes, we have a chance to propose some minor issues to be fixed.
[
10:44am
]
nbelaevski
:
alexsmirnov: ok, thanks. we can discuss this later
[
10:44am
]
LexD left the chat room.
[
10:45am
]
alexsmirnov
:
In the "[ADMIN] EG Audio from today's meeting (was: REMINDER [ADMIN] EG Meeting Next Week)" email Ed puts issue numbers to review and vote for Rev A.
[
10:45am
]
nbelaevski
:
alexsmirnov: right, I saw e-mail on that
[
10:45am
]
balunasj_
:
alexsmirnov: agreed - lets review, but I'd like to start the core and client lib talks.
[
10:46am
]
balunasj_
:
alexsmirnov: We should review at next weeks team meeting, but should probably start with a forum post and we'll begin the conversation
[
10:46am
]
balunasj_
:
nbelaevski: your choice - core or client lib first?
[
10:47am
]
nbelaevski
:
let's take client lib first
[
10:47am
]
•
balunasj_
 
our first multiple choice meeting
[
10:47am
]
balunasj_
:
ok - http://community.jboss.org/wiki/RichFaces40ALPHA2ClientLibStatus
[
10:47am
]
balunasj_
:
pyaschenko1: can you get us started with a review and update
[
10:47am
]
balunasj_
:
?
[
10:49am
]
pyaschenko1
:
balunasj_: component API article not done yet, but almost done
[
10:49am
]
•
balunasj_
 
thinking we should push that update event for JSF update - part of status report
[
10:49am
]
pyaschenko1
:
balunasj_: I'll add How to use Event
[
10:49am
]
balunasj_
:
pyaschenko1: thats ok - just give an overview and then we'll dig in deeper
[
10:50am
]
pyaschenko1
:
balunasj_: RichFace.Event API first version done
[
10:51am
]
pyaschenko1
:
balunasj_: Need to be inserted in tables to test what we need in API also
[
10:51am
]
balunasj_
:
ok
[
10:51am
]
pyaschenko1
:
balunasj_: work on Position API has been started
[
10:52am
]
balunasj_
:
I'm confused by "Codebase for client-side library left almost untouched since A1 "
[
10:52am
]
balunasj_
:
you've been working on it right?
[
10:54am
]
pyaschenko1
:
balunasj_: Events and Position - parts of this, and base component
[
10:54am
]
pyaschenko1
:
balunasj_: and component API
[
10:54am
]
balunasj_
:
ok that is what I thought
[
10:54am
]
abelevich
:
<pyaschenko1> : we will test events at the begging of next week ... ok?
[
10:55am
]
amarkhel left the chat room. (Read error: 110 (Connection timed out))
[
10:55am
]
pyaschenko1
:
abelevich: ok
[
10:56am
]
balunasj_
:
pyaschenko1: nbelaevski : is queue work separate from this, or part of the same area since it seem central to the requests?
[
10:56am
]
pyaschenko1
:
balunasj_: Implementation of cleanup for AJAX updates depends on EG and mojarra tem
[
10:56am
]
pyaschenko1
:
team
[
10:56am
]
nbelaevski
:
balunasj_: separate work
[
10:56am
]
balunasj_
:
nbelaevski: ok
[
10:57am
]
balunasj_
:
nbelaevski: just to be on same page - the "cleanup" work is the events we've discussed with EG right?
[
10:57am
]
nbelaevski
:
balunasj_: yes
[
10:57am
]
pmuir joined the chat room.
[
10:58am
]
balunasj_
:
k
[
10:58am
]
alexsmirnov
:
pyaschenko: Do we have an issue in Jsf bur trekking to include to Rev A ?
[
10:59am
]
nbelaevski
:
alexsmirnov: let me check
[
11:01am
]
balunasj_
:
pyaschenko1: nbelaevski : the requirements look good from my point of view for A2
[
11:01am
]
nbelaevski
:
alexsmirnov: seems no
[
11:02am
]
balunasj_
:
"bur trekking" ?
[
11:02am
]
nbelaevski
:
balunasj_: ok, hope we'll get enough time for prototyping
[
11:02am
]
ilya_shaikovsky
:
bug tracking
[
11:02am
]
nbelaevski
:
balunasj_: bug tracker
[
11:02am
]
balunasj_
:
hehe - ok that one stumped me
[
11:03am
]
balunasj_
:
I'm concerned about the estimates though
[
11:03am
]
balunasj_
:
it will be difficult for me to get these into the schedule this way
[
11:03am
]
balunasj_
:
even some guess would be good
[
11:03am
]
alexsmirnov
:
balunasj: I got out of coffee at home
[
11:04am
]
balunasj_
:
just put "?" next to them like you did for the others.
[
11:04am
]
nbelaevski
:
5 days for the prototype I think...
[
11:04am
]
balunasj_
:
alexsmirnov: can't have that
[
11:04am
]
nbelaevski
:
balunasj_: all seems to be crucial to introduce at this early stage
[
11:05am
]
prabhat joined the chat room.
[
11:05am
]
balunasj_
:
nbelaevski: agreed it is not the tasks them selves but several of the have no estimates
[
11:06am
]
balunasj_
:
if we can get some more clarity on those it will at least give me a place holder for the tasks in the project.
[
11:07am
]
pmuir left the chat room. ("This computer has gone to sleep")
[
11:07am
]
balunasj_
:
I think things like the yahoo performance rules could slip if needed, but much of this will be needed for the next batch of component migrations - like dnd etc..
[
11:07am
]
nbelaevski
:
balunasj_: ok, I've added 2*5 days for prototyping
[
11:08am
]
balunasj_
:
ok
[
11:08am
]
nbelaevski
:
balunasj_: yes
[
11:08am
]
balunasj_
:
once I get all of the various tasks into a schedule we'll be able to see where we need more info
[
11:09am
]
nbelaevski
:
we had a concern about base behavior classes when we touched the topic the last time
[
11:09am
]
amitev2 is now known as amitev.
[
11:09am
]
balunasj_
:
nbelaevski: you mean the unified component API, or something specific to behaviors?
[
11:09am
]
nbelaevski
:
so I think it makes sense to dig into this shortly
[
11:10am
]
nbelaevski
:
balunasj_: this is thought of as a set of bevaior classes that users can use as base building block
[
11:10am
]
nbelaevski
:
balunasj_: examples of this are drag, drop, tooltip activator, toggle control, ...
[
11:11am
]
balunasj_
:
unified component API - or something else?
[
11:11am
]
balunasj_
:
most of these seem like true behaviors to me btw
[
11:11am
]
nbelaevski
:
balunasj_: set of JS classes that implement some behavior, e.g. completing drop when mouse button is up
[
11:12am
]
nbelaevski
:
balunasj_: unified components API is the API that allows to find component on the client and work with it
[
11:12am
]
nbelaevski
:
balunasj_: while component can integrate several behaviors
[
11:12am
]
balunasj_
:
gotcha thanks
[
11:12am
]
balunasj_
:
yes
[
11:12am
]
nbelaevski
:
example of the unified components API is the calling convention we use for#{ rich:component(...)}
[
11:13am
]
nbelaevski
:
what I think about this is that while users are given CDK, they can't reuse our JS code
[
11:13am
]
balunasj_
:
sure
[
11:13am
]
nbelaevski
:
it's just hard for reuse and there seems to be the problem
[
11:14am
]
balunasj_
:
yeah - it would be good to have users access this common stuff.
[
11:14am
]
nbelaevski
:
we can go on with some of existing UI libraries or build our own where it's lacking functional
[
11:15am
]
nbelaevski
:
that's all I want to express on that for now
[
11:15am
]
balunasj_
:
ok, well I certainly like the idea of having common functionality available to users who are building components
[
11:16am
]
balunasj_
:
plus it will make development easier as well.
[
11:16am
]
balunasj_
:
ok so action items on client lib, or is there more to go over now?
[
11:17am
]
nbelaevski
:
for A2 that's all
[
11:17am
]
nbelaevski
:
of coarse, it there are no questions/comments
[
11:18am
]
balunasj_
:
this is an area I want to dig more, and have not had the time, so I'll review and we'll cover things on forums or other meetings
[
11:19am
]
balunasj_
:
so action items for client lib:
[
11:19am
]
balunasj_
:
update estimates
[
11:19am
]
balunasj_
:
some of the items seem to be in jira already, but review and add if needed
[
11:20am
]
balunasj_
:
what about docs, and QE requirements here?
[
11:20am
]
nbelaevski
:
JSDocs for API + examples/guidelines
[
11:20am
]
nbelaevski
:
for QE requirements - performance testing
[
11:20am
]
nbelaevski
:
including:
[
11:21am
]
nbelaevski
:
- memory leaks
[
11:21am
]
nbelaevski
:
- global namespaces pollution
[
11:21am
]
nbelaevski
:
- execution speed
[
11:21am
]
balunasj_
:
agreed - lets get these captures as well
[
11:21am
]
balunasj_
:
anything else before we move on to core?
[
11:21am
]
nbelaevski
:
testing in portlet environment (execution of different script versions side-by-side)
[
11:22am
]
nbelaevski
:
unit tests were declared
[
11:22am
]
balunasj_
:
nbelaevski: ooh that a tricky one ( the portlet one )
[
11:22am
]
nbelaevski
:
probably set of Selenium tests for APIs like positioning
[
11:22am
]
balunasj_
:
unit tests were in there already right?
[
11:22am
]
nbelaevski
:
balunasj_: yes, should be in the list
[
11:22am
]
nbelaevski
:
or you mean in 3.3.x?
[
11:23am
]
balunasj_
:
nbelaevski: would that be covered by testing components that use them, or would QE need to develop their own you think
[
11:23am
]
lfryc left the chat room. (Remote closed the connection)
[
11:23am
]
balunasj_
:
nbelaevski: I'm referring to the status - unit tests are already discussed there - or is this something different
[
11:24am
]
nbelaevski
:
balunasj_: if this is provided for end-users, then set of tests for this is necessary
[
11:24am
]
nbelaevski
:
balunasj_: no, nothing different
[
11:25am
]
balunasj_
:
agree with that and the idea should be captured, but that should be part of CDK test suite i think, and at this point a lower priority.
[
11:25am
]
balunasj_
:
at least until we are farther along
[
11:25am
]
nbelaevski
:
balunasj_: also for me it looks simpler to test API thoroughly and do basic integration tests
[
11:25am
]
balunasj_
:
at first we are going to be the one consumer of the api.
[
11:26am
]
nbelaevski
:
balunasj_: yes, but this seems to be simpler for us also
[
11:26am
]
balunasj_
:
nbelaevski: ok - I could see that.
[
11:28am
]
balunasj_
:
lets capture these and add to status
[
11:28am
]
balunasj_
:
we should move on to core topics since we only have 30 minutes
[
11:29am
]
nbelaevski
:
right
[
11:29am
]
balunasj_
:
http://community.jboss.org/wiki/RichFaces40ALPHA2CoreFrameworkFeaturesStatus
[
11:29am
]
balunasj_
:
so nbelaevski can you get us started here?
[
11:29am
]
nbelaevski
:
yes
[
11:29am
]
nbelaevski
:
we've migrated several features since A1
[
11:30am
]
nbelaevski
:
see list in status
[
11:30am
]
nbelaevski
:
"near terms tasks" section is empty, because I'm going to work on CDK some more time - we could skinning there
[
11:30am
]
nbelaevski
:
but it's in the separate article
[
11:31am
]
nbelaevski
:
for the longer-term tasks
[
11:31am
]
nbelaevski
:
1) Unit testing - components delivered in A2 should be covered by unit tests
[
11:32am
]
nbelaevski
:
currently there's a small amount of component tests for tables
[
11:32am
]
nbelaevski
:
so planned activities there is to uncover testing frameworks we are going to use in more details
[
11:32am
]
nbelaevski
:
with something like cheatsheet/small article & examples
[
11:33am
]
balunasj_
:
agreed on skinning being separate
[
11:33am
]
nbelaevski
:
I'm already using JSFMock, but haven't yet worked with JSFUnit
[
11:34am
]
nbelaevski
:
we had one more testing environment implemented by Alex Smirnov and it's already used for framework tests
[
11:34am
]
balunasj_
:
nbelaevski: I think the cheatsheet/examples would be great for the wiki too, where we can point people to our expectations.
[
11:34am
]
nbelaevski
:
balunasj_: yes
[
11:34am
]
balunasj_
:
nbelaevski: another test env?
[
11:35am
]
balunasj_
:
can you or alexsmirnov explain some more?
[
11:35am
]
nbelaevski
:
it's framework/trunk/test-base
[
11:35am
]
balunasj_
:
ok I'll review myself then.
[
11:35am
]
nbelaevski
:
it seems to be migrated into the same suite as JSF Mock, however I haven't checked this yet
[
11:36am
]
balunasj_
:
nbelaevski: ok
[
11:36am
]
nbelaevski
:
balunasj_: that's the environment that uses staging server
[
11:36am
]
nbelaevski
:
balunasj_: so the question is with JSFUnit
[
11:36am
]
balunasj_
:
nbelaevski: ok - I was about to ask the purpose of the env
[
11:37am
]
nbelaevski
:
balunasj_: it allows to run request/response in staging server and process it using HtmlUnit
[
11:37am
]
nbelaevski
:
balunasj_: it = "test-base" project
[
11:38am
]
nbelaevski
:
balunasj_: especially considering the points on JSFUnit that Alex has announced
[
11:38am
]
alexsmirnov
:
nbelaevski: This is jsf-test project that has been created to replace richfaces-test in the 3.3 branch. I think it is more convinient for our needs ( component testing ) then JSFUnit is, because JSFUnit was targeted to test applications, not a frameworks.
[
11:38am
]
nbelaevski
:
alexsmirnov: I agree with that
[
11:39am
]
ppitonak left the chat room. (Read error: 110 (Connection timed out))
[
11:39am
]
nbelaevski
:
balunasj_: so I'd suggest to continue with jsf-test project, not JSFUnit
[
11:39am
]
balunasj_
:
alexsmirnov: have you looked at arguilian - it is project pete leads that sounds similar in concept.
[
11:40am
]
balunasj_
:
nbelaevski: I'm ok with that JSFUnit might be ok for end user apps, but I think there are some issues with our needs
[
11:40am
]
nbelaevski
:
balunasj_: can you please give the link?
[
11:40am
]
balunasj_
:
nbelaevski: perhaps we'll look again some time
[
11:40am
]
nbelaevski
:
balunasj_: we are goign to start with unit tests very soon
[
11:40am
]
balunasj_
:
http://community.jboss.org/docs/DOC-14376?uniqueTitle=false
[
11:40am
]
balunasj_
:
and
[
11:41am
]
balunasj_
:
for a related one called shrinkwrap ( might be of limited use atm )
[
11:41am
]
balunasj_
:
http://community.jboss.org/wiki/ShrinkWrap
[
11:41am
]
alexsmirnov
:
balunasj: I've never heard about that. What is arguilian ?
[
11:42am
]
nbelaevski
:
it's arquilian, not arguilian
[
11:42am
]
balunasj_
:
sorry bad speller
[
11:42am
]
balunasj_
:
alexsmirnov: the first link is for that one
[
11:43am
]
balunasj_
:
it might be too early for our use, but you know pete is responsive and
[
11:43am
]
nbelaevski
:
balunasj_: I haven't heard too, need to look closer...
[
11:43am
]
balunasj_
:
yeah take a look - might not be our main solution
[
11:43am
]
balunasj_
:
but worth looking into and maybe prototyping something
[
11:44am
]
nbelaevski
:
ok, this goes to action items then
[
11:45am
]
nbelaevski
:
can we go on to the next item?
[
11:46am
]
balunasj_
:
please
[
11:46am
]
alexsmirnov
:
balunasj: On the first look, that project has a different target. It run tests in JEE environment. Because our components has no EJB/JMS/CDI dependencies, it would be overcomplex for out goals.
[
11:47am
]
nbelaevski
:
2) partial updates for iteration components
[
11:48am
]
nbelaevski
:
already discussed on the forum, need to complete discussion, create wiki page on that and proceed with the implementation
[
11:48am
]
nbelaevski
:
as we are doing tables, this seems naturally fit into A2
[
11:49am
]
nbelaevski
:
3) standard skinning migration - discussed this yesterday
[
11:49am
]
balunasj_
:
agreed- however if needed can 2) be delated - it looks to be a 2 week task?
[
11:50am
]
•
balunasj_
 
thinking of priorities with schedules and such
[
11:50am
]
nbelaevski
:
balunasj_: yes, this can be tough
[
11:51am
]
balunasj_
:
ok
[
11:51am
]
balunasj_
:
s/delated/delayed
[
11:52am
]
nbelaevski
:
4) framework initialization - draft implementation is here. I want alexsmirnov to take a quick look before I finalize it (some TODOs to complete, JavaDoc, unit testing)
[
11:52am
]
nbelaevski
:
5) Review BaseRenderer/RendererUtils etc. Remove obsolete code from them - can be delayed if lack of time
[
11:53am
]
nbelaevski
:
some obsolete code already removed
[
11:53am
]
balunasj_
:
4) the system listener part or other aspects?
[
11:53am
]
nbelaevski
:
balunasj_: yes, system listeners
[
11:53am
]
balunasj_
:
I think that removing obsolete code is important for a project as large as RichFaces, but agree is could be delayed.
[
11:54am
]
balunasj_
:
I'll add that point for later review - perhaps a full review at some point in one of the BETAs
[
11:54am
]
nbelaevski
:
balunasj_: I'm removing legacy code from time to time, so it's ongoing
[
11:55am
]
nbelaevski
:
6) Separate RichFaces.js into modules - that's under question. I'm going to assign this to pyaschenko1
[
11:55am
]
balunasj_
:
k
[
11:56am
]
nbelaevski
:
7) Enhanced diagnostic logging - I'm not completely satisfied with the logging system we have for now - going to review this additionally
[
11:56am
]
balunasj_
:
agreed - I'd like to review that as well, but may have to to just see the results from pyaschenko1 investigation
[
11:57am
]
balunasj_
:
7) you mean the logger code, or at what level we are using it?
[
11:58am
]
nbelaevski
:
there seems a lack of information for thorough diagnostics
[
11:58am
]
nbelaevski
:
Resolve SLF4J JBoss 6 conflict
[
11:59am
]
nbelaevski
:
a variant of Windows .DLL hell, but in Java world
[
11:59am
]
balunasj_
:
yes that would be good - I know there has been a lot of discussion around that.
[
11:59am
]
nbelaevski
:
I don't want separate distributions for JBoss, GF, etc.- this needs to be resolved somehow
[
12:00pm
]
balunasj_
:
nbelaevski: agreed - we can not and will not do that - I would push hard - as I think pete and others would too if AS was inflexible
[
12:00pm
]
balunasj_
:
almost all of the tasks have estimates so that should be good for scheduling
[
12:01pm
]
nbelaevski
:
balunasj_: that'll be our small push for flexibility
[
12:01pm
]
nbelaevski
:
9) Implement support for skin-based CSS files - discussed yesterday
[
12:01pm
]
balunasj_
:
yup
[
12:02pm
]
nbelaevski
:
passed via all points
[
12:02pm
]
nbelaevski
:
anybody wants to add?
[
12:02pm
]
balunasj_
:
thinking....
[
12:02pm
]
nbelaevski
:
alexsmirnov: ilya_shaikovsky: ^
[
12:03pm
]
balunasj_
:
what about using project stage for various items
[
12:04pm
]
balunasj_
:
such as logging, or output compression, or something else?
[
12:04pm
]
alexsmirnov
:
JSF 2.0 User java logging that is part of JRE and should work everywhere. If we got a troubles with custom logging framework we would switch to java logging too.
[
12:04pm
]
•
balunasj_
 
brainstorming
[
12:04pm
]
balunasj_
:
alexsmirnov: to be honest I've gone back and forth with that one.  Less features, but we don't need to worry about logging then.
[
12:04pm
]
nbelaevski
:
alexsmirnov: I prefer Log4J - it's easily configurable
[
12:05pm
]
balunasj_
:
alexsmirnov: plus nearly all logging utils can work with it
[
12:05pm
]
balunasj_
:
nbelaevski: it is easy to configure, but that would still require a user to have log4j in app
[
12:05pm
]
balunasj_
:
need to think on that one more
[
12:05pm
]
alexsmirnov
:
nbelaevski: Really, logging is up to container implementation and should be configured there.
[
12:06pm
]
nbelaevski
:
balunasj_: yes, but bridging frameworks are there to the rescue
[
12:06pm
]
nbelaevski
:
alexsmirnov: that's true
[
12:07pm
]
alexsmirnov
:
The other solution is our own wrapper that can forward messages to any particular framework as common-logging does.
[
12:07pm
]
balunasj_
:
alexsmirnov: but that would be another set of code to maintain
[
12:08pm
]
alexsmirnov
:
I already created such one in the CDK to easy switch between Maven/Ant/Eclipse etc.
[
12:09pm
]
nbelaevski
:
balunasj_: "what about using project stage for various items" - I used it for logging in ResourceHandler
[
12:09pm
]
alexsmirnov
:
Every tool has its own logging system, so common-logging does not work there.
[
12:09pm
]
balunasj_
:
nbelaevski: good - I was just thinking of other like the hot deployment of CSS that we talked about yesterday
[
12:10pm
]
nbelaevski
:
any chance to expand javax.faces.context.ExternalContext.log(String, Throwable) with log levels indicator?
[
12:10pm
]
balunasj_
:
alexsmirnov: true, even that could switch o JRE logging if we needed to
[
12:10pm
]
balunasj_
:
nbelaevski: that might be a good one for the JSF update
[
12:11pm
]
nbelaevski
:
balunasj_: right, then it can be routed to container API
[
12:12pm
]
alexsmirnov
:
balunasj: ExternalContext log forwards messages to appropriate ServletContext methods that also have no level, so it is even more global issue.
[
12:12pm
]
nbelaevski
:
balunasj_: I suggest to create forum thread to brainstorm on ProjectStage usage
[
12:13pm
]
nbelaevski
:
balunasj_: so that massive components development will employ best practices from it
[
12:13pm
]
pmuir joined the chat room.
[
12:13pm
]
nbelaevski
:
alexsmirnov: anything in Sevlets 3 to address this?
[
12:13pm
]
balunasj_
:
nbelaevski: agreed - I'll start that one.
[
12:14pm
]
nbelaevski
:
balunasj_: thanks!