phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] proposal-branch; property


From: Joseph Engo
Subject: Re: [Phpgroupware-developers] proposal-branch; property
Date: Thu, 06 May 2004 21:35:02 -0400
User-agent: Mozilla Thunderbird 0.6 (Windows/20040502)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I had a little time to quickly run through the property app.  A few
things I noticed right off the bat, which I am sure
you are still working on are ...

- - table names don't have phpgw_pro prefix (pro for example, you can
use what ever you want for your app, as long as it separates things)
- - sprintf(): Too few arguments on the "main screen", which appears to
make most things not work
- - Missing title for ops, a good example on how to use these is in
notes.  This is mainly for the history

Are you going for a full port to the new API ?  Are you going to make
this application available for both versions ?
Are you going to keep the same code base for both ?

Depending on how you plan on doing this, is how you can go about your
coding.  There are many interesting and powerful
feature that you can take advantage in the new API.  But, it would be
an all or nothing change.  For example, datamine
~ ... you can link other applications records to your own records.  You
can attach notes and tasks to a building for example.
Datamine still needs a lot of work, I wouldn't go too overboard on
adding this, because its going to be cleaned up a lot soon.

The current way datamine works is pretty sloppy, its proof of
concept.  Me and Seek3r are working on new cleaner ways to handle
everything.  One thing I am pretty sure that will stick is the way we
grab data from an app.

For example, lets say you want to provide linking an invoice to a
note.  Your datamine location would be property.invoice
In your invoice class you need a function called _read(), which
accepts 2 parameters.  id number and dm_type.

There are 3 types of dm_types right now.
N - Normal record, not linked in anyway.  Shows up in the normal list
for that location, notes.base.index for example
D - Hard datamine link (This type is changing to 'H' BTW).  This is a
record that is ONLY available if you view the record
its attached to.  For example, if its attached to tasks.base.4 the
only way to see the record is if you look at task #4
S - Symbolic link, this is a record thats available if you look at the
original location AND the linked location.
~    For example:  notes.base.12 linked to property.invoice.5  If you
view note #12, it will say there is a link to an invoice
~    show the invoice, and provide a "more details link".  Now, if you
where to look at invoice #5, it would also say its
~    linked from note #12.

Both types are useful in different settings.  "For more information on
this calendar entry, look at this message board posting"
which would be a symbolic link.  "This account is Frank Rizzo's
brothers, cousins, sisters former roommate", that note only
pertains to that account.  Don't clog up the notes system by showing a
note thats only in reference to 1 item.  ACL, once finished
will also play a big part in this.  Even though an item is linked,
only those with access can see the link.

Back to the _read() function, if used properly (look at notes for
example), this function is used from both inside notes
and from datamine.

Another thing I would make use of is history, its very easy to plug
into.  Notes has a good example of its use.

If you need more info on any of this, let me know.  I am going to
repost some of the information above about datamine
in the wiki, so people can read up on it there.  I can also expand it
when things get set in stone about its use.

Adding things like _read() and _update() will make it easier to
convert over to the datamine structure later.

Also, another thing is the _'s in front of function names.  We haven't
gotten a chance to explain this yet, which I should
post in the wiki as well :P

A single _ is for protected functions.  Those functions can be called
within phpGW ONLY.  You can NOT call those functions
from the interface.  (Browser, SOAP or XML-RPC).  notes can call it,
but XML-RPC can't for example.

Double _ is for private functions __take_overworld() .. these
functions can ONLY be called within the current class.

Now, keep in mind, this only works if developers make use of
execMethod().  I will hound people who by pass this by
manually creating a class and calling a private function. :P

Depending on how you are going about your port, will depend on my
futher feedback.  If you are going for a full port, expect a ton of info
to come flying your way :P

Dan Kuykendall wrote:

| I was planning on giving it a shot tonight
|
| sigurdne wrote:
|
|> Did anyone had the time to look at the ported "porperty" ?
|>
|> In order to navigate - you have to set your permissions in the
|> property admin menu Also the dateformat has to be set in
|> preferences (temporary placed in property-preferences)
|>
|> There is a small db-glitch in api/class.prefs.php that has to be
|> fixed:
|>
|> line 170: alter to (might no be necessary)
|>
|> if (! is_object($rs = $GLOBALS['phpgw']->db->Execute($sql)))
|>
|> and line 177: alter to
|>
|> $this->data[$args['account_id']][$args['app'].'.'.$args['name']]
|> = $rs->fields['pref_value'];
|>
|>
|> The main missing features (I have temporary localy in the app
|> added support for vfs(sql),conf,acl2,appsession and addressbook)
|> are: - the ability to send email-notification from the helpdesk
|> submodule - the oproc functionality (add/alter table/column) -
|> categories - Groups (of users) - substitute for
|> $GLOBALS['phpgw_info']['flags']['noframework'] = True; -
|> substitute for $GLOBALS['phpgw_info']['flags']['headonly']=true;
|> - substitute for $GLOBALS['phpgw_info']['flags']['app_header']
|>
|> There are still issues of course...
|>
|> Sigurd
|>
|>
|>
|>
|> _______________________________________________
|> Phpgroupware-developers mailing list
|> address@hidden
|> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
|>
|
|
| _______________________________________________
| Phpgroupware-developers mailing list
| address@hidden
| http://mail.gnu.org/mailman/listinfo/phpgroupware-developers


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAmufF/AzmiD/o0voRAi8CAJ918r+b0hm5MXlwJPEGnu5bdrNmKwCfU3GE
6oTEH8ykNfgaoIq/LHXfD+U=
=i2II
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]