/[A3C]/lib/A3C.pod
This is repository of my old source code which isn't updated any more. Go to git.rot13.org for current projects!
ViewVC logotype

Annotation of /lib/A3C.pod

Parent Directory Parent Directory | Revision Log Revision Log


Revision 205 - (hide annotations)
Thu Jun 19 19:05:26 2008 UTC (11 years, 7 months ago) by dpavlin
File size: 4715 byte(s)
rename views into better names as result of writing documentation
for AJAX part of jifty
1 dpavlin 204 =head1 NAME
2    
3     A3C = AAAC; AAA from "Authentication, Authorization and Accounting" and C from "CARNet".
4    
5     =head1 DESCRIPTION
6    
7 dpavlin 205 This page describes general idea about A3C application and current status of implementation.
8 dpavlin 204
9 dpavlin 205 Oppinions should be attributed to Dobrica Pavlinusic, and not other developers :-)
10     It's surposed to convey a story which is coherent enough for new developer
11     to join into project. Most of other documentation is more useful when
12     developing and looking into code usage (if it's not documented and tested,
13     it doesn't exist) but this part is delivered as pure POD for reading pleasure.
14    
15 dpavlin 204 =head1 LDAP
16    
17     Implement LDAP entry and edit interface (insteresting problem since most
18     values can have multiple entries which doesn't map nicely to relational
19     schema)
20    
21     This can in turn be broken down into following tasks:
22    
23     =head2 Import data from existing LDAP server
24    
25     C<bin/import-ldap.pl> has embedded documentation
26    
27     =head2 Query existing LDAP server
28    
29     Since we are creating local copy of data, we need easy way to ask master
30     LDAP server for data. L<A3C::LDAP> provides way to query LDAP and receive
31     something similar enough to L<Jifty::Collection> so that L<A3C::View>s
32     doesn't have to be edited to switch from Jifty models to LDAP
33     data.
34    
35     =head2 Create new entries and edit existing ones
36    
37     We are in the middle of migaration from (generic) L<A3C::Model::Person> and
38     L<A3C::Model::Organization> to our custom L<A3C::Model::hrEduOrg> and
39     L<A3C::Model::hrEduPerson>
40    
41     Most views I guess, will be implemented by subclassing L<Jifty::View::Declare::CRUD>.
42     Right now L<A3C::View::Organization> is such implementation.
43    
44     Planned C<A3C::View::hrEduPerson> will implement another such view, and I
45     hope to see some kind of code reuse there (which should probably move to
46     C<Jifty::Plugin::TableCRUD>.
47    
48     =head2 Virtual LDAP server to publish data
49    
50     This part is in planning stage, and it will probably be based on L<Net::LDAP::Server>.
51    
52     =head1 Existing LDAP schema
53    
54     First, we needed a clever way to import existing LDAP schema into Jifty. So,
55     C<bin/ldap2model.pl> helper was created to handle that.
56    
57     Some entries in LDAP schema have fixed list of attributed, and L<A3C::AAIEduHr>
58     implements fetcher (with cache) for that data.
59    
60     =head1 Legacy portal integration
61    
62     =head2 Parse PHP config files
63    
64     Configuration files in PHP is only place in which part of portal
65     configuration is specified. To handle it in A3C, we use
66     L<A3C::Model::StrixInstance> which agregates all instance data. Parser is
67     implemented by L<A3C::PHP>
68    
69     =head2 Connect to remote database
70    
71     Implemented in two different ways:
72    
73     =head3 Direct SQL execution
74    
75     L<A3C::Action::StrixSQL> and interface as L<A3C::View::Strix/sql>.
76    
77     =head3 Fetching data hashes
78    
79     C<Strix> (which doesn't link well from on-line documentation so you will
80     have to take a look in C<lib/Strix.pm>) implements pure DBI code (ported
81     from php) to access data directly. Keep in mind that this data have to be
82     cached for any resonable performance. On the other hand, data can be
83 dpavlin 205 structured usefully, for example trees are structured in useful way for
84     direct output to JSON.
85 dpavlin 204
86     If tree has C<class> key, it can be set to C<error> so that we can mark
87     errors in data using same CSS class in views. This might be useful convention.
88    
89 dpavlin 205 I prefer to keep this file documented up to level that make it's usage from Jifty and
90     C<t/50-strix.t> makes sanse, but not more than that.
91    
92 dpavlin 204 =head1 HTML
93    
94     We don't generate HTML using templates. In fact, all HTML is encoded in perl
95     code using L<Template::Declare>. This allows easy generation of valid HTML,
96     high-level templates which are perl code and easy skinning using CSS.
97    
98     C<share/web/static/css/app.css> is used to store application specific CSS.
99     It should probably be split into several files (Jifty will concatenate them
100     for us anyway) for easier maintenance, probably by same logic as view names
101     to skip additional step of mapping when human are watching into code.
102    
103 dpavlin 205 In long run, this should allow us to refactor templates at code level and
104     create different re-usable widgets which brings us to following topic...
105    
106     =head1 AJAX
107    
108     Jifty's way of AJAX are L<Jifty::Manual::PageRegions>.
109    
110     =head2 Strix navigation
111    
112     L<http://a3c.skole.hr/strix/navigation>
113    
114     For now, we have implementation of two-level select which is in sync with
115     instance clipboard (implemented by L<A3C::Model::StrixInstanceSelection> and
116     L<A3C::View::Strix> and L<A3C::Action::StrixSelectSite>. This is
117     good candidate to refactor into reusable widget on it's own.
118    
119 dpavlin 204 =head1 BUGS
120    
121     Many probably, documented in C<TODO> which is also useful for quick overview
122     what changed between versions if svn commit log is too detailed allthough
123     first line of commit message might be good summary of each individual
124     change.

  ViewVC Help
Powered by ViewVC 1.1.26