twingled/SampleNewsPosts/org.netfrag.yakka%20-%20ApiDoc%20available%20-%20powered%20by%20phpDocumentor.twingle

@subject org.netfrag.yakka - ApiDoc available - powered by phpDocumentor
@date 2003-03-06 14:05
@topic news
@x-publisher-transport nntp
@x-publisher-name ms outlook ;-(
@newsgroup nfo.yakka, nfo.dev.php
@cc bareface, jonen, flo

Hi there,

we just started generating some API Docs from the php code
living in the cvs-repository by now.

Looks nice....  - so we included Yakka.

@link http://netfrag.org/docs/code/api/org.netfrag/


Please msg if this is *not* desired.


Or msg for further suggestions: At 'org.netfrag.glib' we started
introducing phpDocumentor's '@subpackage' tags, which
can be used to make subgroups of your classes inside a main
'@package'.

I would propose making the following "Subpackages" for Yakka:
    o YakkaBase (grouping all the abstract classes)
    o YakkaStorage (grouping all the storage and respective adapter classes)
    o YakkaEngine (the engine and all helper classes)

Another possible or additional grouping scheme could be:
    o YakkaEngine (all the core stuff from the different groups above)
    o YakkaPage (the page-specific stuff: preparation (storage-retrieve),
rendering (xsl), etc.)
    o YakkaUser (the user-specific stuff: authentication (login),
permissions, roles, etc.)


phpDocumentor seems to be *very* flexible on this level. We can also use
'@name' tags to give different names to things on a per-file level. (besides
the class level)

Having done this with 'org.netfrag.glib', the childnodes inside the "Files"
parent nodes (below "Subpackages") browsable with the navigator located
at the left bottom frame show up with the namespace declaration we used
there.
(e.g. Application::Core, DesignPattern::MVC)

So you are able to supply kinda "module-names" - as said, on a per-file
level:
Already programming this way we have been starting making up "components"
living in the filesystem at the place designated through the namespace.
(See Perl's module architecture)
        php::mkComponent (shortcut exists but is deprecated (by now):
mkObject)


Now being able to integrate this with an automated documentation-system just
rocks.


--greets, joko.

p.s.: Integrating this with an automated programming system would rock even
more....  ;-)

Okay okay, programming is for programmers. But lets be honest: Linux and the
free software community still has no running highlevel (easy to use)
component
system on the base level.
Neither has the free part of Web-Development.

[...] the text coming here got too long [...]    (flo knows my post
scriptums......)

===   refactored to a new post: "Industry Application Servers - do we need
them?"   ===
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?" ===
MailToCvsAdmin">MailToCvsAdmin	ViewVC Help
Powered by ViewVC 1.1.26