"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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...