| 1 |
joko |
1.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
