| 12 |
developing and looking into code usage (if it's not documented and tested, |
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. |
it doesn't exist) but this part is delivered as pure POD for reading pleasure. |
| 14 |
|
|
| 15 |
|
=head1 Models |
| 16 |
|
|
| 17 |
|
Models in Jifty are at perl level objects (with validation and |
| 18 |
|
canonicalization) and tables in database. |
| 19 |
|
|
| 20 |
|
For a start, we implement some magic documented in L<A3C::Record> on records |
| 21 |
|
(rows in database). |
| 22 |
|
|
| 23 |
|
Then, we need to mungle data without re-thinking SQL queries which would |
| 24 |
|
produce same results, so there is L<A3C::SQL> which produce objects that |
| 25 |
|
look like L<Jifty::Collection>s, but aren't. This allows us to switch into |
| 26 |
|
SQL in views if needed. |
| 27 |
|
|
| 28 |
|
This method is not perfect, and shouldn't be used instead of Jifty models |
| 29 |
|
just to write SQL because it doesn't do any permission checking. However, |
| 30 |
|
it's a huge help for compex C<GROUP BY> and C<JOIN> queries which are hard |
| 31 |
|
to express using L<Jifty::DBI>. |
| 32 |
|
|
| 33 |
|
If we needed to generate those queries from within program (from user data, |
| 34 |
|
for example) something like L<Fey::SQL> would be much better tool. |
| 35 |
|
|
| 36 |
=head1 LDAP |
=head1 LDAP |
| 37 |
|
|
| 38 |
Implement LDAP entry and edit interface (insteresting problem since most |
Implement LDAP entry and edit interface (insteresting problem since most |
Parent Directory
| 
Revision Log
| 
Patch