| 1 |
@subject org.netfrag.yakka - ApiDoc available - powered by phpDocumentor |
| 2 |
@date 2003-03-06 14:05 |
| 3 |
@topic news |
| 4 |
@x-publisher-transport nntp |
| 5 |
@x-publisher-name ms outlook ;-( |
| 6 |
@newsgroup nfo.yakka, nfo.dev.php |
| 7 |
@cc bareface, jonen, flo |
| 8 |
|
| 9 |
Hi there, |
| 10 |
|
| 11 |
we just started generating some API Docs from the php code |
| 12 |
living in the cvs-repository by now. |
| 13 |
|
| 14 |
Looks nice.... - so we included Yakka. |
| 15 |
|
| 16 |
@link http://netfrag.org/docs/code/api/org.netfrag/ |
| 17 |
|
| 18 |
|
| 19 |
Please msg if this is *not* desired. |
| 20 |
|
| 21 |
|
| 22 |
Or msg for further suggestions: At 'org.netfrag.glib' we started |
| 23 |
introducing phpDocumentor's '@subpackage' tags, which |
| 24 |
can be used to make subgroups of your classes inside a main |
| 25 |
'@package'. |
| 26 |
|
| 27 |
I would propose making the following "Subpackages" for Yakka: |
| 28 |
o YakkaBase (grouping all the abstract classes) |
| 29 |
o YakkaStorage (grouping all the storage and respective adapter classes) |
| 30 |
o YakkaEngine (the engine and all helper classes) |
| 31 |
|
| 32 |
Another possible or additional grouping scheme could be: |
| 33 |
o YakkaEngine (all the core stuff from the different groups above) |
| 34 |
o YakkaPage (the page-specific stuff: preparation (storage-retrieve), |
| 35 |
rendering (xsl), etc.) |
| 36 |
o YakkaUser (the user-specific stuff: authentication (login), |
| 37 |
permissions, roles, etc.) |
| 38 |
|
| 39 |
|
| 40 |
phpDocumentor seems to be *very* flexible on this level. We can also use |
| 41 |
'@name' tags to give different names to things on a per-file level. (besides |
| 42 |
the class level) |
| 43 |
|
| 44 |
Having done this with 'org.netfrag.glib', the childnodes inside the "Files" |
| 45 |
parent nodes (below "Subpackages") browsable with the navigator located |
| 46 |
at the left bottom frame show up with the namespace declaration we used |
| 47 |
there. |
| 48 |
(e.g. Application::Core, DesignPattern::MVC) |
| 49 |
|
| 50 |
So you are able to supply kinda "module-names" - as said, on a per-file |
| 51 |
level: |
| 52 |
Already programming this way we have been starting making up "components" |
| 53 |
living in the filesystem at the place designated through the namespace. |
| 54 |
(See Perl's module architecture) |
| 55 |
php::mkComponent (shortcut exists but is deprecated (by now): |
| 56 |
mkObject) |
| 57 |
|
| 58 |
|
| 59 |
Now being able to integrate this with an automated documentation-system just |
| 60 |
rocks. |
| 61 |
|
| 62 |
|
| 63 |
--greets, joko. |
| 64 |
|
| 65 |
p.s.: Integrating this with an automated programming system would rock even |
| 66 |
more.... ;-) |
| 67 |
|
| 68 |
Okay okay, programming is for programmers. But lets be honest: Linux and the |
| 69 |
free software community still has no running highlevel (easy to use) |
| 70 |
component |
| 71 |
system on the base level. |
| 72 |
Neither has the free part of Web-Development. |
| 73 |
|
| 74 |
[...] the text coming here got too long [...] (flo knows my post |
| 75 |
scriptums......) |
| 76 |
|
| 77 |
=== refactored to a new post: "Industry Application Servers - do we need |
| 78 |
them?" === |
Parent Directory
| 
Revision Log
