FYI - I have added a comment and link to this forum thread to  https://jira.jboss.org/jira/browse/RF-7281 which is a request for this type of component.

First - WOW - that was fast ;-)

A few questions/comments:

• This was built on 3.3.X - do you know how much effort would be needed for 4.0.X
  • We have no plans for further 3.3.X releases
  • So I would like to target something like this for 4.0 - wdyt?
• Could you provide a simple war example of this?
• Your comments and concerns regarding using 3rd party plugins are right on.
  • That is one of the problems of reling on these, it can limit flexibility, and future support.
  • I have not looked into gritter plugin, so I'm not sure how complex it is

In general RichFaces tends to favor customization, skinning, and stability, to rapid integration of 3rd party plugins.  So it sounds like we are on a similar page.  In order to support some of the options you discuss I think modification or customer impl may be needed.

This is great though, lets keep the conversation going!

-Jay

Hi Bernard,

I've had problems checking out from SVN the 4th version before. Now i've managed to get in, but i'm confused by it's structure: /root contains some dirs which contain branches,trunk,tags.

Please instruct me what do I need to check out in order to start building components for RichFaces-4.0.0.

Here is the document that describes this structure: http://community.jboss.org/wiki/RichFaces40BuildSystem . Speaking shortly, there is a number of modules in http://anonsvn.jboss.org/repos/richfaces/root/ , each of them can be versioned separately. If you want to do project build, you can checkout the whole structure from root and do:

mvn clean install -Ptrunk,components

Otherwise, you can create Maven project for your component (some archetypes are already available in CDK module) and use nightly builds of CDK from JBoss snapshots Maven repository.

My greatest concern now is how customizable and skinable this component should be.

Usual requirement for this is certain set of:

- facets/attributes: content customization, event handlers, component settings, etc.

- set of rich-* CSS classes for all significant HTML elements

- predefined CSS classes wired to skin parameters + images

rich:messages accept marker facets to display user provided icons for different message severity.

I wonder why isn't this done via CSS, i.e. user could provide classes for each severity and icons could be loaded as background images.

Providing icon urls as attributes (warnIcon,infoIcon,etc) seems poor solution to me. What do you think?

We've just followed markup from our HTML designer. I guess that's a variation of "spacer.gif" pattern - inline image element that's dimension can be controlled. In 4.x we've dropped off IE6 & quirks mode support from requirements, so in the latest design markups we use background images as you've described.

Again problem with gritter script is that it uses hardcoded template and substitutes some tokens with summary, detail, img url, so I don't know how to use embeded UIGraphic components (I would need to retrive the url from them) and thus using faces is out.

I think we can do two things to deal with the problem (this is in case we don't modify source code):

- Ask the author to make plugin more customizable (suggest a patch)

- Pass another template markup in setup method like this:

$.extend($.gritter.options, { 
     fade_in_speed: 100, // how fast notifications fade in (string or int)
     fade_out_speed: 100, // how fast the notices fade out
     time: 3000, // hang on the screen for...
     _tpl_item: '...markup template...'
});

Bernard,

I just wonder if template config code could be placed in script, so that it would not be rendered on each re-render of growl.

Yes, that's the best place.

We should have 4 background image classes for each severity so that resource url can be different and thus cached.

Yes, four images.

Which skin properties should we re-use? We need border color and background color.

I think generalBackgroundColor & panelBorderColor should be ok for this.

yay! Thats really fast and sounds cool!!

Will review the component and demo today.. but quick concern about new skin properties.. in general current skin properties is minimal set. And we took it as minimal as possible in order to avoid richfaces-css analog product to appear . We make our best to introduce base look and feel by this minimal set and provide rich- classes which could extend this easilly.

So how about next proposal.. popups with different severities could still be differentiated by default icons but have still the panel look and fell which Nick already proposed. And for the end-developers - it still could be really easy custoizable by using CSS classes which should differs for different popups.

If end-dev wants to have different background then backgroundPanelColor or  wants to have different color for each severity then he shall provide copy of current image with different color.

slightly confused by

provide copy of current image

he shall be able just to redefine corresponding rich class with specifyin custom bg-color.

Soryy if misunderstand somthing.

HI Bernard,

Very sorry for not getting back to this sooner, there has been a sudden flurry of activities and meetings.

I'm a little concerns because all of this effort is for 3.3.X, and at this point we're all moving on to 4.0.  If you do add your code to 3.3.X then it would be available in snapshot releases, but we're not planning another 3.3.X release at this time. 

Have you given any thought back to 4.0.X?  Nick, Alex, and I will be redesigning the 4.0 build structure in the next couple of weeks to be easier to navigate and understand.

As for the component.  I agree with only having one "style" while allowing the image to shift.  This way skinning will be easier and get the best "bang for the buck".  While still allowing customizations for those that want with images, and styles.

For curvy corners - I think they do look good, and would prefer them.  My question to you would be trade offs.  What do you see as tradeoffs for this?

Next Actions:

We'll need you to sign a CLA agreement ( just a standard open source contributors agreement ).  You can do that and check it out here - https://cla.jboss.org/ .  This will allow us to use your code, and is the path to committer rights eventually.

Then either you can or we can create update  https://jira.jboss.org/jira/browse/RF-7281,  Then we can upload your code, talk more about how to get into the project, and see whats next :-)

Please think about the 4.0.X branch?  It would help us to get some outside opinions on the CDK, and any missing component parts.

Thanks Again,

Jay

I also agree we need to get some more default styling in place - make it look cool :-)

Excellent Bernard!!

I will take a look as soon as I can.

Prepping for our team meeting at #richfaces irc.freenode.net.

That update is really great!  I also like the updated styling :-)