osalvador
Future enhancements?
Someone actually read my post regarding "Template Creation 301".
Should I modify the public code for tePLSQL to handle "fragments" as discussed in that document? (The term "fragment" comes from RFC for URI)
This is how my personal copy operates at this moment.
MK
note url points to a "private" forum https://community.oracle.com/docs/DOC-991641?sr=inbox
I'm about to say "no" for this one.
The need to handle "fragments" appears to be more of a feature of a "template editor" than something that should be specific to a code generation engine.
Any comments from anyone?
Hi Mike, I'm very interested in helping with the template editor use the "fragment" idea. Have you made any starts into a template editor. Have you prototyped something in Apex. Peter Burgess.
I have come to the conclusion that the "template editor based on the 'fragment' idea" needs to be independent from the code generation engine.
Right now, the editor I have (APEX 4.2 on 11g XE) greatly modifies the tePLSQL table (and adds new tables).
I'll be working on the editor in separate repository.
Hi Mike,
The concept of "fragments" can be easily implemented in TE_TEMPLATES table, a template can be the same as a fragment, and include nested templates.
Personally I think it is better to reduce the size of the templates to simplify maintenance and maximize the PL / SQL packages that help code generation, we could call them "helpers".
I am very interested in the progress that you develop in the other repository.
Right now, I'm storing one "fragment" per row in TE_TEMPLATES.
"fragments", "nested templates", and "helpers" might all be the same thing. I'm using the term "fragments" because I access them via URI syntax. ("fragments" is defined by the RFC for URI)
Example break down:
| If you include fragment.. | You generate code for ... |
|---|---|
| /mytapi/functions/insert#documentation | creates the comment, in PL/Doc format, for the function |
| /mytapi/functions/insert#name | name of the function (reuse everywhere) |
| /mytapi/functions/insert#specification | create just the specification; reuse in the BODY |
| /mytapi/functions/insert#declaration | creates just the declaration of the function. (ie the code between 'AS' and 'BEGIN' |
| /mytapi/functions/insert#body | create just BODY portion of the code. (ie the code between 'BEGIN' and 'EXCEPTION'/'END' |
| /mytapi/functions/insert#exceptions | create just the exception (ie the code between 'EXCEPTION' and 'END' |
The template /mytapi/functions/insert would include all of the above "fragments". (Creating the TAPI by looping over all templates found in /mytapi/functions/* is implied.)
From the editor standpoint, it was easier for me to create the editor if each fragment was on a different row in a child table of TE_TEMPLATES. I'm currently moving the editor away from being tePLSQL specific.
From the TE_TEMPLATES standpoint, "fragments" could be combined together and stored in a single row. How? I don't know. Also, would the extraction be efficient when generating the code?
From the TEPLSQL package stand point, I feel that the TAPI for TE_TEMPLATES should be responsible for extracting the specific "fragment".
For now, I vote that we just keep tePLSQL as it is and record "one fragment per row".
MK
If anyone is interested, I have a "proof of concept" template editor based on the above concept running on apex.oracle.com.
It still needs work. But, you can develop a collection of templates "very easily". (right now, import/export of custom XML format is the only format supported.)
Let me know if anyone is interested in kicking it around.
MK
FYI - a "fragment", in this context, is synonymous to a "block" in #36
The solution for #36 uses the Java dot notation for the names (see #43 for naming convention)