Noel --
Regarding our discussion of why pure-CMP provides a higher and better level of
abstraction than does thinking and talking and coding in terms of tables/sql/ddl
and how we can uplevel nukes to the pure-CMP level...
"hxp" wrote : I'm organizing and preparing a bunch of relevant mater
Noel --
The demo for my client is now over with, so I can turn my attention back to Nukes
backend development... I'm organizing and preparing a bunch of relevant material, and
will be posting it in the next few days --- and it will make this whole subject a lot
clearer. I'll post back here whe
for the record, i was thinking about using the clob/xml idea to store data in the
database, not for any kind of rendering/transformations.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3830839#3830839
Reply to the post :
http://www.jboss.org/index.html?mo
Noel --
"noel.rocher" wrote : Hi Howard,
| I don't know if I've really understood you.
|
Sorry; I'll do a more complete explanation after the big demo I'm preparing is
finished :-)
-- Howard
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3830836#383083
Hi Howard,
I don't know if I've really understood you.
What I think about putting XML and XSL things in tables is that this will simplify a
lot the Nukes webapp administration(upgrading, backup, ...).
In one project I've used some data out of the database, in files. It was not a really
good i
Noel --
I agree 99% with your assessment -- and it is certainly applicable to more than just
the News module.
IMO, the winning formula is to use XSLT templates to transform XML, with the .xsl ---
and all other species of .xml --- to be derived dynamically when appropriate, but in
general to b
Hi all,
XML approach is surely the most dynamic way.
Certainly an other CLOB table will be necessary for XSLT data that will describe the
rendering process. Something like a "available templates for news rendering".
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewt
Joachim --
OK, keep your eyes open for a thread in this forum with the phrase "Pure-CMP" in the
title... I'll start it within the next week or two.
Since you're short on time (know how you feel; I wear more than a dozen hats myself
;-)) ...I may have a quicky to ask from you... if I haven't go
anonymous wrote :
| would you be interested in helping out on converting some of the modules?
|
In priciple I would love to, but I am afraid that time is very limited for me. So
limited that while I am very interested in Nukes, I have not been able to do more than
just try the 1.0 release
Joachim --
You've got it -- pure-CMP is definitely the answer! I've been quietly working on a
pure-CMP approach for Nukes; I've already redone one of the modules so that zero
DDL/SQL is required, and it works nicely... but I'm waiting to speak up about it till
after 1.1 is out and the core de
anonymous wrote :
| My question is how are we going to handle upgrades to nukes and modules when the
schemas change for them? I know how postnuke handled them but I don't think we could
do somthing like that because we are using cmp.
If every DB access uses CMP can this can very simply be do
well - i'm pushing towards a release of the news module, but it is only going to be a
"1.0" release, which means it won't have a lot of nifty features etc.
once we it gets released w/ the 1.1 nukes release, i'm not quite sure if it's really
"in development" anymore, so making schema changes wou
My feeling is that the news module has not ever been officially released yet. It has
been said it is under development. I don't see any problem with changing the schema at
this stage because it is a module under developement.
My question is how are we going to handle upgrades to nukes and module
thx! i'm definately leaning more towards the generic approach myself. i'd like to
avoid migration scripts as much as possible.
we're using this model w/ castor to handle a similiar issue at the day job. we sell
some products that share 75% of the same info, just the product specific attributes
anonymous wrote : i was thinking that i could just expose a "clob" field on a single
table and addtional info for that format could be stored as xml, but this may cause
performance problems b/c of the un/marshalling that needs to be done.
|
I strongly vote for this approach. Otherwise, as the
15 matches
Mail list logo
