[jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Re: Max -- followup to our JBossWorld conversation re: SEAM

[max.andersen@jboss.com]

"hxp" wrote : 
  | It was good to chat with you at JBossWorld, and I'm following up on our conversation about fixes/improvements to the SEAM CRUD FreeMarker Templates.  
  | 

Cool :) 

anonymous wrote : 
  | You mentioned that further progress was waiting on some bandwidth from Gavin, and I'm wondering what the current outlook is.
  | 

Gavin is busy doing other things; so feel free to attack it ;)

anonymous wrote : 
  | I've tracked JIRA tasks & roadmap, and except for the somewhat-related HBX-670, there doesn't appear to be much on the subject of the composite keys, or seam 1.0.x.GA compatibility.
  | 

i don't understand why 1.0.x.GA compability is still an issue...It works for me (or at least did during JBossWorld :)

composite keys is just a known issue.
Similar to the seam templates not being able to handle recursive associations.

anonymous wrote : 
  | Then I noticed JBIDE-337, and the forum discussion, and realized that you all have your focus on something far more ambitious that what we discussed. 
  | 

yes, but this will not invalidate work on the crud code generation code.

anonymous wrote : 
  | So now it's not clear to me whether the fixup of the templates is going to happen prior a whole new SEAM IDE coming out... but it would be really good if there were a fixup to keep this wonderful tool operational in the interim :)
  | 

of course. Just need someone to step up and contribute ;)

anonymous wrote : 
  | 
  | 	seam/*:
  | 
  | 		1) compatible/compliant with jboss-seam-1.0.1.GA
  | 

I would like to be told what exactly is missing here.

anonymous wrote : 
  | 		2) edit.jsp.ftl & find.jsp.ftl fixed for the composite key issue (+ any other files that need to be fixed to support compound keys?)... and for proper relationship traversal.
  | 

It might be interesting to simplify alot of the code in this CRUD generation to simply be REST'full and/or not be too fancy with using all of Seam features (like workspaces etc.) ...it's more important that the code is clean and understandable than being feature rich.

Note, if you can come up with simple generated code and still be feature rich then great ;)

anonymous wrote : 
  | 		3) migration of *.jsp.ftl to *.xhtml.ftl, to support the Facelet model instead of the older JSP model  (+ add faces-config.xml.ftl, and will need facelet jars)
  | 

ok. facelets would be a definite plus (amongst others we can validate the generated code better in the junittests for the codegenerator)

anonymous wrote : 
  | 		3a) optionally, as much convergence with the structure of the (Facelets-based) Booking example as possible
  | 

Similarity is good.

anonymous wrote : 
  | 		4) persistence.xml.ftl needs to be parameterized, at minimum to reflect the datasource that was reverse-engineered (later, good to have option to generate persistence.xml for a different intended target datasource than the rev-eng'd one).
  | 

yes for the persistence.xml to be more complete.
Changing the datasource for the output is *low* priority since that it would be better to just go change it manually or some other tool/wizard/editor than adding "complexity".

we actually need this persistence.xml generation to be an independent exporter like the hibernate cfg.xml and pojo exporter is.

anonymous wrote : 
  | 		5) optionally, whatever else can quickly be built-into the CRUD templates to show-off the rich feature set of SEAM 1.0.1.GA (but should *not* require SEAM 1.1; when it's time to support more than 1.0.1.GA, consider having HibernateTools support multiple template sets, for output to different SEAM version targets).
  | 

I would be a little conservative here and focus on the previous 4 first.
But it of course depends on what features you are thinking about.

anonymous wrote : 
  | 		6) *not* for now, by important soon: the template-generated SEAM project must match the layout structure contemplated in JBIDE-337, and the selected artifacts must be re/generatable into a pre-existing SEAM project without wrecking it....  plus the eventual JBIDE-337 design must take into account that many developers will prefer to clone & fork existing SEAM projects (such as from the examples, or from their own past work) rather than use a wizard... all of which leads to the need for tool-supported libraries of reusable work (including user-created FreeMarker templates), and open-ended easily-extensible library-aware wizards that support such reuse.
  | 

The current SeamExporter is basically a very crude "bundler" of alot of other templates and exporters.  This was just intended for a "quick and dirty" seam generation.

I want to split these into more atomic parts which then can be (optionally) used individually to be used in both Ant and the Eclipse tools.

anonymous wrote : 
  | 	pojo/Ejb3TypeDeclaration.ftl

		Need some way to turn off schema and/or catalog generation in the output, even if they exist in the input -- we want a test for something like "if clazz.table.catalog?exists AND is_desired_in_the_output" --- 
	
  | <#if clazz.table.schema?exists>
  | 	 ,schema="${clazz.table.schema}"
  | </#if>
  | <#if clazz.table.catalog?exists>
  | 	 ,catalog="${clazz.table.catalog}"
  | </#if>

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961207#3961207

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961207