Seam contributor competition

What about SEAM DOCX MODULE?

We could use docx4j (https://dev.plutext.org/trac/docx4j).

We could generate dinamically docx documents starting from xhtml templates (like seam mail/excel).

I used this library in a jsf project: my users could create page templates (with header and footer) and could dynamically add content using an advanced textarea (TinyMCE). My parser was not complete (it not handle all possible combinations of images / tables / etc): this could be an opportunity to improve ...

I have an idea for anyone who wants to take it on:

Currently in JSF 2.0, your ajax requests specify areas or items of the screen to redraw in the render attribute of the f:ajax tag. This sort of implies a tight coupling between separate components on a page. To get around this it would be nice to have the option to use events and observers to determine which areas of the screen to redraw instead of explicitly declaring them in every ajax request tag.

The idea is that a CDI or Seam event is fired in the listener from your ajax request. During rendering, components on the screen can 'observe' certain events that may have been fired during the processing of the listener, so that they know whether to redraw or not.

eg. Given an ajax actionlistener:

<h:commandButton value="click">
   <f:ajax listener="myBean.fireSomeEvent()"
</h:commandButton

Then in myBean an event is fired:

public void fireSomeEvent() {
  // do stuff
  myEvent.fire(obj)
}

Then somewhere in the page we have components that would be rerendered based on observing certain events:

<s:observes events="myEvent,someOtherEvent">
   <h:dataTable ...
 </s:observes>

What I can't answer right now is what links the events listed in the observes tag's events attribute to CDI events, that's an exercise for the contributor

It would also be great to allow Wicket components to 'observe' events in the same manner mentioned above for jsf.

So you can register components to listen for certain events (maybe by event qualifier type?)

Label myLabel = new Label(changeMeModel);
 EventRegistrar.registerComponents(MyEvent.class,myLabel,myOtherLabel,...);

Registering controls for events would automatically call their setOutputMarkupId(true).

And in an Ajax control's onSubmit() method there would be no need to target components explicitly:

public void onSubmit(AjaxRequestTarget target,Form form) {
  // do stuff
  myEvent.fire();

  // Let the event registrar decide which components to add to the target based on the events they observe
  EventRegistrar.updateObservers(target);
}

What would be ideal is if the EventRegistrar.updateObservers wasn't even necessary.

This should allow for a looser coupling between ajax controls and the components they affect.

Hi Shervin,

Seam 3 only...

Can module leads participate? ;-)

Nicklas Karlsson wrote on Jul 28, 2010 01:14:
Can module leads participate? ;-)

Of course!

Please check out my module:

Query Service Project

The goal of this project is to reduce the amount of code when it comes to writing queries and services. Your queries are attached directly to the interface. That's it, no need to write any more code besides that.

@QueryService
public interface UserQueryService
{
@Query("SELECT user FROM User user WHERE user.active = TRUE");
List<User> findActiveUsers();
}

Feel free to post on the github site as well.

Thanks,

Walter

It would probably nice if you could use EL in the queries like

@Query("select c from Customer c where c.id=#{order.customer.id}")