[transfer-dev] Re: transfer.codegen (BER)
gen:commentComment Text Here/gen:comment Which would generate the comment text wrapped with the getCommentStart () and getCommentEnd() tags !--- Comment Text Here --- or !-- Comment Text Here -- or /* Comment Text Here */ Anyways, I'm not really sure that I really *need* this at this point since I could just type out the comments normally in the template.. I was thinking it would be nice to have in a gen:comment since my generators already know what the comment start and end looked like. On Jun 13, 6:19 pm, Mark Mandel mark.man...@gmail.com wrote: Adam, I'm not 100% sure what you are talking about could you give me an example? Are you saying you want a standard Template comment? i.e. a comment syntax that is always ignored in the template? Mark On Sun, Jun 14, 2009 at 12:55 AM, Adam Drew epne...@gmail.com wrote: Mark, I feel like I need a comment tag for the templates so that whatever comment method is being used by my generator is used in the template.. in this way I could standardize my template writing regardless if I'm wrighting CFCs, CFMs, XMLs, or DDLs,.. I'm going to review the block, compact, and template tags to see if i am missing something and come up with the answer on my own.. but let me know if I am missing something or if you have any thoughts about this. AD -- E: mark.man...@gmail.com W:www.compoundtheory.com --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: transfer.codegen (BER)
To be more specific, here is a dump of the type of precision data i'm looking to use with the DDL struct CHAR_OCTET_LENGTH 0 COLUMN_DEFAULT_VALUE[empty string] COLUMN_NAME id COLUMN_SIZE 18 DECIMAL_DIGITS 0 IS_FOREIGNKEY NO IS_NULLABLE NO IS_PRIMARYKEY YES ORDINAL_POSITION1 REFERENCED_PRIMARYKEY N/A REFERENCED_PRIMARYKEY_TABLE N/A REMARKS [empty string] TYPE_NAME numeric() identity --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: transfer.codegen (BER)
To follow up on topic.. I got my xml generator working beautifully by overloading the init() function and setting setCommentStart(! --); .. I ended up creating an AbstractXMLGenerator which I extend myself for the different types of xml config I need for my forms, validations, searchs, audits, and many other areas of object specific metadata configurations... Now I'm thinking that to be able to generate DDL based on Transfer.XML seams to be the next logical step for me because basically right now I am doing the complete reverse of that process with an cb interceptor and a set of Service/Gateway objects.. I created a CFDatasourceGateway which uses DBInfo based on the concepts found in the TransferConfig project, and I have my TranseferConfigService use it to generate me some transfer.xml based on some specific conventions I've used in my SQL database. This introspects the DB and generates the transfer.xml (w/Packages, M2O, O2M + M2M Relationships)... The next interceptors loads Transfer and runs my generators based on that So if I could implement a DDL generator in addition this would allow me to either build the database up in SQL with my abstract model conventions and then generate my transfer.xml from that.. or just build my transfer.xml and then generate the database based on that... either way, having this ability to go either way with the development process would be nothing short of sick... I will post any progress on the subject, Thanks for the suggestions. -Adam On Jun 12, 9:21 pm, Mark Mandel mark.man...@gmail.com wrote: A side note on all this... if anyone wants to write a generator to output DDL table generation based on Transfer meta data... that would be pretty cool ;o) Mark On Fri, Jun 12, 2009 at 10:20 AM, Adam Drew epne...@gmail.com wrote: But what IF you have the cb app redirect the client to the static ColdDoc URL no matter what.. the afterConfigurationLoad interceptor would *update* the ColdDoc's static BER folder before redirecting the client there... and all you would have to do after a significant API change was restart the public CB app with a fwreinit password. Maybe I had tooo much Hop Stooopid tonight. On Jun 11, 8:11 pm, Mark Mandel mark.man...@gmail.com wrote: Because ColdDoc does static generation of the HTML files, not a runt time generation. Could always do it on a scheduled task I guess... ;o) Mark On Fri, Jun 12, 2009 at 10:04 AM, Adam Drew epne...@gmail.com wrote: nvm.. i know what codldoc is cause i am using it...I was over reading your statement but seriously now.. with thinking about this quickly ... couldn't I set up a lightweight coldbox app to introspect my SVN repsoitory, check out the latest trunk to a secured current ber folder, in order to then have ColdDoc load and display the API? .. basically afterConfigurationLoad If my SVN trunk revision is greater then that of the local working copy (publicy documented version) for my current BER, then update the working copy before loading ColdDoc On Jun 11, 7:44 pm, Adam Drew epne...@gmail.com wrote: ColdDoc..? Is this a Mark+Luis project happening under my radar? What i mean is who is the *we* you reference with the ColdDoc and what is the problem with the BER? I have been playing with some java SVN component that lets me introspect Trunks, Branches and Tags and the whole self documenting SVN concept is pretty interesting to me.. I would love to see more resources! I'll let you know if anything comes up with my codegen experiance.. I have written 3 custom generators at this point.. a DecoratorGenerator, ServiceGenerator, GatewayGenerator.. and now I've begun my MetadataGenerator... it's kinda clear for me at this point what i need to do.. My concern was the handling of the CFML comment in XML .. I had previously gone through the AbstractBaseGenerator (actually first thing).. but some how overlooked the idea that that i could just setCommentStart() and setCommentEnd ().. Now I am wondering should I do this in my run() implementation or do I override the init() caling super.init() so I can then setCommentStart () and setCommentEnd()? -AD On Jun 11, 7:14 pm, Mark Mandel mark.man...@gmail.com wrote: No worries! Let me know if you run into any issues. Mark On Fri, Jun 12, 2009 at 9:12 AM, Adam Drew epne...@gmail.com wrote: This is why your the man.. because you knew what i wanted and you gave it right to me.. The two things you should probably take note of : In the init() of the AbstractBaseGenerator, you can see where I have: setCommentStart(! ---); setCommentEnd(---); THANKS. On Jun 11, 7:05 pm, Mark Mandel mark.man...@gmail.com wrote: Ah very nice! This would be easier, if
[transfer-dev] Re: transfer.codegen (BER)
Mark, I feel like I need a comment tag for the templates so that whatever comment method is being used by my generator is used in the template.. in this way I could standardize my template writing regardless if I'm wrighting CFCs, CFMs, XMLs, or DDLs,.. I'm going to review the block, compact, and template tags to see if i am missing something and come up with the answer on my own.. but let me know if I am missing something or if you have any thoughts about this. AD --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: transfer.codegen (BER)
Adam, I'm not 100% sure what you are talking about could you give me an example? Are you saying you want a standard Template comment? i.e. a comment syntax that is always ignored in the template? Mark On Sun, Jun 14, 2009 at 12:55 AM, Adam Drew epne...@gmail.com wrote: Mark, I feel like I need a comment tag for the templates so that whatever comment method is being used by my generator is used in the template.. in this way I could standardize my template writing regardless if I'm wrighting CFCs, CFMs, XMLs, or DDLs,.. I'm going to review the block, compact, and template tags to see if i am missing something and come up with the answer on my own.. but let me know if I am missing something or if you have any thoughts about this. AD -- E: mark.man...@gmail.com W: www.compoundtheory.com --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: transfer.codegen (BER)
A side note on all this... if anyone wants to write a generator to output
DDL table generation based on Transfer meta data... that would be pretty
cool ;o)
Mark
On Fri, Jun 12, 2009 at 10:20 AM, Adam Drew epne...@gmail.com wrote:
But what IF you have the cb app redirect the client to the static
ColdDoc URL no matter what.. the afterConfigurationLoad interceptor
would *update* the ColdDoc's static BER folder before redirecting the
client there... and all you would have to do after a significant API
change was restart the public CB app with a fwreinit password. Maybe I
had tooo much Hop Stooopid tonight.
On Jun 11, 8:11 pm, Mark Mandel mark.man...@gmail.com wrote:
Because ColdDoc does static generation of the HTML files, not a runt time
generation.
Could always do it on a scheduled task I guess... ;o)
Mark
On Fri, Jun 12, 2009 at 10:04 AM, Adam Drew epne...@gmail.com wrote:
nvm.. i know what codldoc is cause i am using it...I was over reading
your statement but seriously now.. with thinking about this
quickly ... couldn't I set up a lightweight coldbox app to introspect
my SVN repsoitory, check out the latest trunk to a secured current
ber folder, in order to then have ColdDoc load and display the
API? .. basically afterConfigurationLoad If my SVN trunk revision is
greater then that of the local working copy (publicy documented
version) for my current BER, then update the working copy before
loading ColdDoc
On Jun 11, 7:44 pm, Adam Drew epne...@gmail.com wrote:
ColdDoc..? Is this a Mark+Luis project happening under my radar?
What
i mean is who is the *we* you reference with the ColdDoc and what is
the problem with the BER? I have been playing with some java SVN
component that lets me introspect Trunks, Branches and Tags and the
whole self documenting SVN concept is pretty interesting to me.. I
would love to see more resources!
I'll let you know if anything comes up with my codegen experiance.. I
have written 3 custom generators at this point.. a
DecoratorGenerator, ServiceGenerator, GatewayGenerator.. and
now
I've begun my MetadataGenerator... it's kinda clear for me at this
point what i need to do.. My concern was the handling of the CFML
comment in XML .. I had previously gone through the
AbstractBaseGenerator (actually first thing).. but some how
overlooked
the idea that that i could just setCommentStart() and setCommentEnd
()..
Now I am wondering should I do this in my run() implementation or do
I
override the init() caling super.init() so I can then setCommentStart
() and setCommentEnd()?
-AD
On Jun 11, 7:14 pm, Mark Mandel mark.man...@gmail.com wrote:
No worries!
Let me know if you run into any issues.
Mark
On Fri, Jun 12, 2009 at 9:12 AM, Adam Drew epne...@gmail.com
wrote:
This is why your the man.. because you knew what i wanted and you
gave
it right to me..
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I
have:
setCommentStart(! ---);
setCommentEnd(---);
THANKS.
On Jun 11, 7:05 pm, Mark Mandel mark.man...@gmail.com wrote:
Ah very nice!
This would be easier, if we had ColdDoc for the BER release,
but I
haven't
worked out the best way to do that...
Where you want to be looking is the AbstractBaseGenerator - as
this
is
what
you will be extending.
Writing your own Generators, you will have to look through the
code
a
bit,
as it is the best resource for doing this sort of stuff.
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I
have:
setCommentStart(! ---);
setCommentEnd(---);
This is where you can tell the generator what code comments
look
like in
whatever you are generating, so you may want to override these
in
your
generator, as you are generting XML and probably want --! and
--
rather
than the extra -
The other thing to look at - check out the API for
writeTemplate(),
since
you are generating XML, you can tell it to escapeCFML=false, so
that you
don't have to use the $$ and {{ and }} syntax - although, maybe
for
XML
you
may want to leave that capability, I'll leave that up to you.
Other than that - protected block should still work, and as
long as
you
have
writeTemplate() point to XML files, it will write XML files.
Have a look at the source for the Decorator generator, and the
API
for
the
AbstractBaseGenerator - it should be pretty clear (hopefuly).
Mark
On Fri, Jun 12, 2009 at 8:54 AM, Adam Drew epne...@gmail.com
[transfer-dev] Re: transfer.codegen (BER)
Ah very nice!
This would be easier, if we had ColdDoc for the BER release, but I haven't
worked out the best way to do that...
Where you want to be looking is the AbstractBaseGenerator - as this is what
you will be extending.
Writing your own Generators, you will have to look through the code a bit,
as it is the best resource for doing this sort of stuff.
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
This is where you can tell the generator what code comments look like in
whatever you are generating, so you may want to override these in your
generator, as you are generting XML and probably want --! and -- rather
than the extra -
The other thing to look at - check out the API for writeTemplate(), since
you are generating XML, you can tell it to escapeCFML=false, so that you
don't have to use the $$ and {{ and }} syntax - although, maybe for XML you
may want to leave that capability, I'll leave that up to you.
Other than that - protected block should still work, and as long as you have
writeTemplate() point to XML files, it will write XML files.
Have a look at the source for the Decorator generator, and the API for the
AbstractBaseGenerator - it should be pretty clear (hopefuly).
Mark
On Fri, Jun 12, 2009 at 8:54 AM, Adam Drew epne...@gmail.com wrote:
Hey Mark,
I started playing with the transfer.codegen functionality in the BER
in an attempt to replace my current usage of TransferConfig+Illudium
PU-36 (riaforge) by implementing a chain of Coldbox Interceptors that
have my special layer to do some *active* codegen during a CB+Transfer
+CS app start up (afterConfigurationLoad + afterAspectsLoad if dev =
true).
I am currently generating concrete objects for my abstract decorators,
gateways and services using the method described above and each of
these are working as expected, and beautifully I might add..
especially with the protected block feature allowing me to re-generate
the *protected* functions in my concrete CFCs as I refine a specific
domain model, all the while leaving the *custom* code in my concrete
objects alone... anyone can say what they want about the practice...
but this really makes me happy :)
Now, I want to generate some custom/specific metadata to use with say
ValidateThis!, Majik, or for that matter any other library, toolkit,
framework, et al..) using the transfer object metadata and other
information i've gathered up during the interceptor chain with my
services + factories...
I have not tried to generate any XML yet as I just started writing the
generator, and then began a template and started to think. I have
reviewed the codegen doc (WIP), and honestly, I have not gone through
the source enough to answer the following questions so, as I work
things out here, I was hoping that maybe you could confirm for me if
things should function the same when generating XML files as with CFCs
in my custom generator? Should my template be named *.xml .. and my
generator write *.xml... Will protected blocks work? ect.
Thanks in advance for considerations extended, and for such an AMAZING
addition to our toolkit.
--
E: mark.man...@gmail.com
W: www.compoundtheory.com
--~--~-~--~~~---~--~~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
You received this message because you are subscribed to the Google Groups
transfer-dev group.
To post to this group, send email to transfer-dev@googlegroups.com
To unsubscribe from this group, send email to
transfer-dev-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
-~--~~~~--~~--~--~---
[transfer-dev] Re: transfer.codegen (BER)
This is why your the man.. because you knew what i wanted and you gave
it right to me..
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
THANKS.
On Jun 11, 7:05 pm, Mark Mandel mark.man...@gmail.com wrote:
Ah very nice!
This would be easier, if we had ColdDoc for the BER release, but I haven't
worked out the best way to do that...
Where you want to be looking is the AbstractBaseGenerator - as this is what
you will be extending.
Writing your own Generators, you will have to look through the code a bit,
as it is the best resource for doing this sort of stuff.
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
This is where you can tell the generator what code comments look like in
whatever you are generating, so you may want to override these in your
generator, as you are generting XML and probably want --! and -- rather
than the extra -
The other thing to look at - check out the API for writeTemplate(), since
you are generating XML, you can tell it to escapeCFML=false, so that you
don't have to use the $$ and {{ and }} syntax - although, maybe for XML you
may want to leave that capability, I'll leave that up to you.
Other than that - protected block should still work, and as long as you have
writeTemplate() point to XML files, it will write XML files.
Have a look at the source for the Decorator generator, and the API for the
AbstractBaseGenerator - it should be pretty clear (hopefuly).
Mark
On Fri, Jun 12, 2009 at 8:54 AM, Adam Drew epne...@gmail.com wrote:
Hey Mark,
I started playing with the transfer.codegen functionality in the BER
in an attempt to replace my current usage of TransferConfig+Illudium
PU-36 (riaforge) by implementing a chain of Coldbox Interceptors that
have my special layer to do some *active* codegen during a CB+Transfer
+CS app start up (afterConfigurationLoad + afterAspectsLoad if dev =
true).
I am currently generating concrete objects for my abstract decorators,
gateways and services using the method described above and each of
these are working as expected, and beautifully I might add..
especially with the protected block feature allowing me to re-generate
the *protected* functions in my concrete CFCs as I refine a specific
domain model, all the while leaving the *custom* code in my concrete
objects alone... anyone can say what they want about the practice...
but this really makes me happy :)
Now, I want to generate some custom/specific metadata to use with say
ValidateThis!, Majik, or for that matter any other library, toolkit,
framework, et al..) using the transfer object metadata and other
information i've gathered up during the interceptor chain with my
services + factories...
I have not tried to generate any XML yet as I just started writing the
generator, and then began a template and started to think. I have
reviewed the codegen doc (WIP), and honestly, I have not gone through
the source enough to answer the following questions so, as I work
things out here, I was hoping that maybe you could confirm for me if
things should function the same when generating XML files as with CFCs
in my custom generator? Should my template be named *.xml .. and my
generator write *.xml... Will protected blocks work? ect.
Thanks in advance for considerations extended, and for such an AMAZING
addition to our toolkit.
--
E: mark.man...@gmail.com
W:www.compoundtheory.com
--~--~-~--~~~---~--~~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
You received this message because you are subscribed to the Google Groups
transfer-dev group.
To post to this group, send email to transfer-dev@googlegroups.com
To unsubscribe from this group, send email to
transfer-dev-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
-~--~~~~--~~--~--~---
[transfer-dev] Re: transfer.codegen (BER)
No worries!
Let me know if you run into any issues.
Mark
On Fri, Jun 12, 2009 at 9:12 AM, Adam Drew epne...@gmail.com wrote:
This is why your the man.. because you knew what i wanted and you gave
it right to me..
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
THANKS.
On Jun 11, 7:05 pm, Mark Mandel mark.man...@gmail.com wrote:
Ah very nice!
This would be easier, if we had ColdDoc for the BER release, but I
haven't
worked out the best way to do that...
Where you want to be looking is the AbstractBaseGenerator - as this is
what
you will be extending.
Writing your own Generators, you will have to look through the code a
bit,
as it is the best resource for doing this sort of stuff.
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
This is where you can tell the generator what code comments look like in
whatever you are generating, so you may want to override these in your
generator, as you are generting XML and probably want --! and -- rather
than the extra -
The other thing to look at - check out the API for writeTemplate(), since
you are generating XML, you can tell it to escapeCFML=false, so that you
don't have to use the $$ and {{ and }} syntax - although, maybe for XML
you
may want to leave that capability, I'll leave that up to you.
Other than that - protected block should still work, and as long as you
have
writeTemplate() point to XML files, it will write XML files.
Have a look at the source for the Decorator generator, and the API for
the
AbstractBaseGenerator - it should be pretty clear (hopefuly).
Mark
On Fri, Jun 12, 2009 at 8:54 AM, Adam Drew epne...@gmail.com wrote:
Hey Mark,
I started playing with the transfer.codegen functionality in the BER
in an attempt to replace my current usage of TransferConfig+Illudium
PU-36 (riaforge) by implementing a chain of Coldbox Interceptors that
have my special layer to do some *active* codegen during a CB+Transfer
+CS app start up (afterConfigurationLoad + afterAspectsLoad if dev =
true).
I am currently generating concrete objects for my abstract decorators,
gateways and services using the method described above and each of
these are working as expected, and beautifully I might add..
especially with the protected block feature allowing me to re-generate
the *protected* functions in my concrete CFCs as I refine a specific
domain model, all the while leaving the *custom* code in my concrete
objects alone... anyone can say what they want about the practice...
but this really makes me happy :)
Now, I want to generate some custom/specific metadata to use with say
ValidateThis!, Majik, or for that matter any other library, toolkit,
framework, et al..) using the transfer object metadata and other
information i've gathered up during the interceptor chain with my
services + factories...
I have not tried to generate any XML yet as I just started writing the
generator, and then began a template and started to think. I have
reviewed the codegen doc (WIP), and honestly, I have not gone through
the source enough to answer the following questions so, as I work
things out here, I was hoping that maybe you could confirm for me if
things should function the same when generating XML files as with CFCs
in my custom generator? Should my template be named *.xml .. and my
generator write *.xml... Will protected blocks work? ect.
Thanks in advance for considerations extended, and for such an AMAZING
addition to our toolkit.
--
E: mark.man...@gmail.com
W:www.compoundtheory.com
--
E: mark.man...@gmail.com
W: www.compoundtheory.com
--~--~-~--~~~---~--~~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
You received this message because you are subscribed to the Google Groups
transfer-dev group.
To post to this group, send email to transfer-dev@googlegroups.com
To unsubscribe from this group, send email to
transfer-dev-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
-~--~~~~--~~--~--~---
[transfer-dev] Re: transfer.codegen (BER)
ColdDoc..? Is this a Mark+Luis project happening under my radar? What
i mean is who is the *we* you reference with the ColdDoc and what is
the problem with the BER? I have been playing with some java SVN
component that lets me introspect Trunks, Branches and Tags and the
whole self documenting SVN concept is pretty interesting to me.. I
would love to see more resources!
I'll let you know if anything comes up with my codegen experiance.. I
have written 3 custom generators at this point.. a
DecoratorGenerator, ServiceGenerator, GatewayGenerator.. and now
I've begun my MetadataGenerator... it's kinda clear for me at this
point what i need to do.. My concern was the handling of the CFML
comment in XML .. I had previously gone through the
AbstractBaseGenerator (actually first thing).. but some how overlooked
the idea that that i could just setCommentStart() and setCommentEnd
()..
Now I am wondering should I do this in my run() implementation or do I
override the init() caling super.init() so I can then setCommentStart
() and setCommentEnd()?
-AD
On Jun 11, 7:14 pm, Mark Mandel mark.man...@gmail.com wrote:
No worries!
Let me know if you run into any issues.
Mark
On Fri, Jun 12, 2009 at 9:12 AM, Adam Drew epne...@gmail.com wrote:
This is why your the man.. because you knew what i wanted and you gave
it right to me..
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
THANKS.
On Jun 11, 7:05 pm, Mark Mandel mark.man...@gmail.com wrote:
Ah very nice!
This would be easier, if we had ColdDoc for the BER release, but I
haven't
worked out the best way to do that...
Where you want to be looking is the AbstractBaseGenerator - as this is
what
you will be extending.
Writing your own Generators, you will have to look through the code a
bit,
as it is the best resource for doing this sort of stuff.
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
This is where you can tell the generator what code comments look like in
whatever you are generating, so you may want to override these in your
generator, as you are generting XML and probably want --! and -- rather
than the extra -
The other thing to look at - check out the API for writeTemplate(), since
you are generating XML, you can tell it to escapeCFML=false, so that you
don't have to use the $$ and {{ and }} syntax - although, maybe for XML
you
may want to leave that capability, I'll leave that up to you.
Other than that - protected block should still work, and as long as you
have
writeTemplate() point to XML files, it will write XML files.
Have a look at the source for the Decorator generator, and the API for
the
AbstractBaseGenerator - it should be pretty clear (hopefuly).
Mark
On Fri, Jun 12, 2009 at 8:54 AM, Adam Drew epne...@gmail.com wrote:
Hey Mark,
I started playing with the transfer.codegen functionality in the BER
in an attempt to replace my current usage of TransferConfig+Illudium
PU-36 (riaforge) by implementing a chain of Coldbox Interceptors that
have my special layer to do some *active* codegen during a CB+Transfer
+CS app start up (afterConfigurationLoad + afterAspectsLoad if dev =
true).
I am currently generating concrete objects for my abstract decorators,
gateways and services using the method described above and each of
these are working as expected, and beautifully I might add..
especially with the protected block feature allowing me to re-generate
the *protected* functions in my concrete CFCs as I refine a specific
domain model, all the while leaving the *custom* code in my concrete
objects alone... anyone can say what they want about the practice...
but this really makes me happy :)
Now, I want to generate some custom/specific metadata to use with say
ValidateThis!, Majik, or for that matter any other library, toolkit,
framework, et al..) using the transfer object metadata and other
information i've gathered up during the interceptor chain with my
services + factories...
I have not tried to generate any XML yet as I just started writing the
generator, and then began a template and started to think. I have
reviewed the codegen doc (WIP), and honestly, I have not gone through
the source enough to answer the following questions so, as I work
things out here, I was hoping that maybe you could confirm for me if
things should function the same when generating XML files as with CFCs
in my custom generator? Should my template be named *.xml .. and my
generator write *.xml... Will protected blocks work? ect.
Thanks in advance for considerations
[transfer-dev] Re: transfer.codegen (BER)
On Fri, Jun 12, 2009 at 9:44 AM, Adam Drew epne...@gmail.com wrote: ColdDoc..? Is this a Mark+Luis project happening under my radar? What i mean is who is the *we* you reference with the ColdDoc and what is the problem with the BER? I have been playing with some java SVN component that lets me introspect Trunks, Branches and Tags and the whole self documenting SVN concept is pretty interesting to me.. I would love to see more resources! heh, you are getting CodexWiki and ColdDoc confused. ColdDoc is the port of JavaDoc that I wrote, that generates all the html documentation you see here: http://docs.transfer-orm.com/html/transferapi/ There is no problem with the BER, it's just that to update BER ColdDoc every time I do a commit... would suck ;o) Now I am wondering should I do this in my run() implementation or do I override the init() caling super.init() so I can then setCommentStart () and setCommentEnd()? I would overwrite the init, just make sure you call super.init() at the top of your own init function. Mark -- E: mark.man...@gmail.com W: www.compoundtheory.com --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: transfer.codegen (BER)
nvm.. i know what codldoc is cause i am using it...I was over reading
your statement but seriously now.. with thinking about this
quickly ... couldn't I set up a lightweight coldbox app to introspect
my SVN repsoitory, check out the latest trunk to a secured current
ber folder, in order to then have ColdDoc load and display the
API? .. basically afterConfigurationLoad If my SVN trunk revision is
greater then that of the local working copy (publicy documented
version) for my current BER, then update the working copy before
loading ColdDoc
On Jun 11, 7:44 pm, Adam Drew epne...@gmail.com wrote:
ColdDoc..? Is this a Mark+Luis project happening under my radar? What
i mean is who is the *we* you reference with the ColdDoc and what is
the problem with the BER? I have been playing with some java SVN
component that lets me introspect Trunks, Branches and Tags and the
whole self documenting SVN concept is pretty interesting to me.. I
would love to see more resources!
I'll let you know if anything comes up with my codegen experiance.. I
have written 3 custom generators at this point.. a
DecoratorGenerator, ServiceGenerator, GatewayGenerator.. and now
I've begun my MetadataGenerator... it's kinda clear for me at this
point what i need to do.. My concern was the handling of the CFML
comment in XML .. I had previously gone through the
AbstractBaseGenerator (actually first thing).. but some how overlooked
the idea that that i could just setCommentStart() and setCommentEnd
()..
Now I am wondering should I do this in my run() implementation or do I
override the init() caling super.init() so I can then setCommentStart
() and setCommentEnd()?
-AD
On Jun 11, 7:14 pm, Mark Mandel mark.man...@gmail.com wrote:
No worries!
Let me know if you run into any issues.
Mark
On Fri, Jun 12, 2009 at 9:12 AM, Adam Drew epne...@gmail.com wrote:
This is why your the man.. because you knew what i wanted and you gave
it right to me..
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
THANKS.
On Jun 11, 7:05 pm, Mark Mandel mark.man...@gmail.com wrote:
Ah very nice!
This would be easier, if we had ColdDoc for the BER release, but I
haven't
worked out the best way to do that...
Where you want to be looking is the AbstractBaseGenerator - as this is
what
you will be extending.
Writing your own Generators, you will have to look through the code a
bit,
as it is the best resource for doing this sort of stuff.
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
This is where you can tell the generator what code comments look like in
whatever you are generating, so you may want to override these in your
generator, as you are generting XML and probably want --! and --
rather
than the extra -
The other thing to look at - check out the API for writeTemplate(),
since
you are generating XML, you can tell it to escapeCFML=false, so that you
don't have to use the $$ and {{ and }} syntax - although, maybe for XML
you
may want to leave that capability, I'll leave that up to you.
Other than that - protected block should still work, and as long as you
have
writeTemplate() point to XML files, it will write XML files.
Have a look at the source for the Decorator generator, and the API for
the
AbstractBaseGenerator - it should be pretty clear (hopefuly).
Mark
On Fri, Jun 12, 2009 at 8:54 AM, Adam Drew epne...@gmail.com wrote:
Hey Mark,
I started playing with the transfer.codegen functionality in the BER
in an attempt to replace my current usage of TransferConfig+Illudium
PU-36 (riaforge) by implementing a chain of Coldbox Interceptors that
have my special layer to do some *active* codegen during a CB+Transfer
+CS app start up (afterConfigurationLoad + afterAspectsLoad if dev =
true).
I am currently generating concrete objects for my abstract decorators,
gateways and services using the method described above and each of
these are working as expected, and beautifully I might add..
especially with the protected block feature allowing me to re-generate
the *protected* functions in my concrete CFCs as I refine a specific
domain model, all the while leaving the *custom* code in my concrete
objects alone... anyone can say what they want about the practice...
but this really makes me happy :)
Now, I want to generate some custom/specific metadata to use with say
ValidateThis!, Majik, or for that matter any other library, toolkit,
framework, et al..) using the transfer object metadata and other
information i've
[transfer-dev] Re: transfer.codegen (BER)
But what IF you have the cb app redirect the client to the static
ColdDoc URL no matter what.. the afterConfigurationLoad interceptor
would *update* the ColdDoc's static BER folder before redirecting the
client there... and all you would have to do after a significant API
change was restart the public CB app with a fwreinit password. Maybe I
had tooo much Hop Stooopid tonight.
On Jun 11, 8:11 pm, Mark Mandel mark.man...@gmail.com wrote:
Because ColdDoc does static generation of the HTML files, not a runt time
generation.
Could always do it on a scheduled task I guess... ;o)
Mark
On Fri, Jun 12, 2009 at 10:04 AM, Adam Drew epne...@gmail.com wrote:
nvm.. i know what codldoc is cause i am using it...I was over reading
your statement but seriously now.. with thinking about this
quickly ... couldn't I set up a lightweight coldbox app to introspect
my SVN repsoitory, check out the latest trunk to a secured current
ber folder, in order to then have ColdDoc load and display the
API? .. basically afterConfigurationLoad If my SVN trunk revision is
greater then that of the local working copy (publicy documented
version) for my current BER, then update the working copy before
loading ColdDoc
On Jun 11, 7:44 pm, Adam Drew epne...@gmail.com wrote:
ColdDoc..? Is this a Mark+Luis project happening under my radar? What
i mean is who is the *we* you reference with the ColdDoc and what is
the problem with the BER? I have been playing with some java SVN
component that lets me introspect Trunks, Branches and Tags and the
whole self documenting SVN concept is pretty interesting to me.. I
would love to see more resources!
I'll let you know if anything comes up with my codegen experiance.. I
have written 3 custom generators at this point.. a
DecoratorGenerator, ServiceGenerator, GatewayGenerator.. and now
I've begun my MetadataGenerator... it's kinda clear for me at this
point what i need to do.. My concern was the handling of the CFML
comment in XML .. I had previously gone through the
AbstractBaseGenerator (actually first thing).. but some how overlooked
the idea that that i could just setCommentStart() and setCommentEnd
()..
Now I am wondering should I do this in my run() implementation or do I
override the init() caling super.init() so I can then setCommentStart
() and setCommentEnd()?
-AD
On Jun 11, 7:14 pm, Mark Mandel mark.man...@gmail.com wrote:
No worries!
Let me know if you run into any issues.
Mark
On Fri, Jun 12, 2009 at 9:12 AM, Adam Drew epne...@gmail.com wrote:
This is why your the man.. because you knew what i wanted and you
gave
it right to me..
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I have:
setCommentStart(! ---);
setCommentEnd(---);
THANKS.
On Jun 11, 7:05 pm, Mark Mandel mark.man...@gmail.com wrote:
Ah very nice!
This would be easier, if we had ColdDoc for the BER release, but I
haven't
worked out the best way to do that...
Where you want to be looking is the AbstractBaseGenerator - as this
is
what
you will be extending.
Writing your own Generators, you will have to look through the code
a
bit,
as it is the best resource for doing this sort of stuff.
The two things you should probably take note of :
In the init() of the AbstractBaseGenerator, you can see where I
have:
setCommentStart(! ---);
setCommentEnd(---);
This is where you can tell the generator what code comments look
like in
whatever you are generating, so you may want to override these in
your
generator, as you are generting XML and probably want --! and --
rather
than the extra -
The other thing to look at - check out the API for writeTemplate(),
since
you are generating XML, you can tell it to escapeCFML=false, so
that you
don't have to use the $$ and {{ and }} syntax - although, maybe for
XML
you
may want to leave that capability, I'll leave that up to you.
Other than that - protected block should still work, and as long as
you
have
writeTemplate() point to XML files, it will write XML files.
Have a look at the source for the Decorator generator, and the API
for
the
AbstractBaseGenerator - it should be pretty clear (hopefuly).
Mark
On Fri, Jun 12, 2009 at 8:54 AM, Adam Drew epne...@gmail.com
wrote:
Hey Mark,
I started playing with the transfer.codegen functionality in the
BER
in an attempt to replace my current usage of
TransferConfig+Illudium
PU-36 (riaforge) by implementing a chain of Coldbox Interceptors
that
have my special layer to do some *active* codegen during a
CB+Transfer
+CS app start up
