Author Topic: Access to PDATA and other 'magic' fields  (Read 12364 times)

SomersetGraham

  • EA User
  • **
  • Posts: 376
  • Karma: +1/-0
    • View Profile
Access to PDATA and other 'magic' fields
« on: March 11, 2010, 08:15:04 pm »
All
I have been trying to create a link between a note and an element feature via automation.
To achieve this I had to update the repository database directly.

It would be good to have access to these fields directly from the API

Would anyone else find this useful?

Graham
Using V12

Makulik

  • EA User
  • **
  • Posts: 400
  • Karma: +0/-0
    • View Profile
Re: Access to PDATA and other 'magic' fields
« Reply #1 on: March 11, 2010, 08:30:34 pm »
Gets my vote!
+1

g.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13387
  • Karma: +566/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Access to PDATA and other 'magic' fields
« Reply #2 on: March 11, 2010, 08:36:28 pm »
Mine too!

Geert

beginner

  • Guest
Re: Access to PDATA and other 'magic' fields
« Reply #3 on: March 11, 2010, 10:17:28 pm »
POLLution + 1

Though I doubt we'll get it as those PDATA are definitely those bit buckets evolving over the years indicating a bad design. Honestly I'd prefer to have a sane object model.

b.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13387
  • Karma: +566/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Access to PDATA and other 'magic' fields
« Reply #4 on: March 11, 2010, 10:42:17 pm »
I think we all do, but the point is that ALL properties should be exposed in the API.
Now it is impossible to change some things without hacking away in the database with the PDATA fields.

Geert

Makulik

  • EA User
  • **
  • Posts: 400
  • Karma: +0/-0
    • View Profile
Re: Access to PDATA and other 'magic' fields
« Reply #5 on: March 11, 2010, 10:42:44 pm »
Aggreed of course! But having access to PDATA fields through the Automation API would at least enable you to put a sane model on top of EAs classes (a bit easier than using direct DB access). I did this anyway in my AddIn.

g.


fwoolz

  • EA User
  • **
  • Posts: 435
  • Karma: +0/-0
  • We have met the enemy, and he is us.<Pogo, 1970>
    • View Profile
Re: Access to PDATA and other 'magic' fields
« Reply #6 on: March 12, 2010, 07:15:54 am »
Totally and wholeheartedly agree. This approach should be extended to the entire database schema, allowing access to things like all fields in t_document, direct API R/W access to RTF documents without having to use a file as an intermediary, etc.
Fred Woolsey
Interfleet Technology Inc.

Always be ready to laugh at yourself; that way, you beat everyone else to the punch.


Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8607
  • Karma: +257/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Access to PDATA and other 'magic' fields
« Reply #7 on: March 12, 2010, 10:15:49 am »
Quote
I think we all do, but the point is that ALL properties should be exposed in the API.
Now it is impossible to change some things without hacking away in the database with the PDATA fields.

Geert
Absolutely! (my emphasis)

And as I've said MANY times....  EA's UI should use the API so that that all the UI functions can by accessed by an Add-in or Script...

In my view this is a fundamental Architectural question.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Dermot

  • EA Administrator
  • EA User
  • *****
  • Posts: 591
  • Karma: +7/-0
    • View Profile
Re: Access to PDATA and other 'magic' fields
« Reply #8 on: March 16, 2010, 04:35:41 pm »
Hmm... has anyone tried using MiscData - see it in:
http://www.sparxsystems.com/uml_tool_guide/sdk_for_enterprise_architect/element2.html

It does state it is Pdata(x).

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8607
  • Karma: +257/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Access to PDATA and other 'magic' fields
« Reply #9 on: March 16, 2010, 05:03:00 pm »
Quote
Hmm... has anyone tried using MiscData - see it in:
http://www.sparxsystems.com/uml_tool_guide/sdk_for_enterprise_architect/element2.html

It does state it is Pdata(x).
Hi Dermot,

We're all well aware of that...  ;)

The implication in access was WRITE access which MiscData doesn't give us..

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

fwoolz

  • EA User
  • **
  • Posts: 435
  • Karma: +0/-0
  • We have met the enemy, and he is us.<Pogo, 1970>
    • View Profile
Re: Access to PDATA and other 'magic' fields
« Reply #10 on: March 17, 2010, 01:38:58 pm »
Ultimately, the AI should, as Paolo has often pointed out, completely shadow the UI such that whatever a user can do manually through the UI, the AI can do the same thing programmatically.

Sparx has offered a caveat in their response to a feature request I sent in, to wit:
Quote
Hello Fred,

Apologies for the much delayed reply.

1. Do Sparx have plans for the StrContent field in the foreseeable
future, or would they be willing to allow this field to be used for
application-specific plain text objects?
- Currently this is used by the Team Review (Forum) and we cannot
guarantee in the foreseeable future that we will not use this field for
other entries.

2. Would Sparx consider allowing custom row entries in t_document
provided that the rules regarding EA's use of the table were followed?
This would allow arbitrary BLOB content (such as images, Autocad DXF or
DWG files, PDF files, etc.) to be stored as element attachments WITHIN
the database rather than as linked files. This encapsulation is
important for cases where a distributed team is working on a project but
not everyone necessarily has access to the linked files.
- We advise against modifying the database as we can not guarantee the
effect on EA's performance.
Note: I've tinkered with custom row entries (along with multiple linked
document entries) in t_document and EA seems to get along quite nicely
with them (it does, however, seem to ignore all but the first linked
document for a given element).

3. Are there any reasons why the listed fields in t_object shouldn't be
used for custom plain text data in Requirement elements?
- Because we can not guarantee that we will not be using them in the
future.

4. Would Sparx consider adding improved Automation Interface support for
the listed fields in t_document (and for the more obscure fields in
t_object while they're at it)? For starters, it would be good to be able
to load linked document RTF directly from a string rather than only from
a file.
- We will add this as a feature request on your behalf to be looked into
for a future date.

5. As an alternative (or additionally - even better) would Sparx
consider adding an option (checkbox in the UI) to treat the element
Notes field as plain rather than Rich Text? This would allow the field
to be used for XML, HTML, and other markup without it being mangled by
the HTML-lite parser used by EA. This probably means another database
hack (maybe to StyleEx or something similar?), but it seems eminently
do-able.
- For now we are not looking at going down that path however, we will
make a note of this.

6. As a side issue, what format does EA use to store RTF files? Is it
compressed (e.g. Zipped)?
- Yes, it is zipped.

However, for future build we are looking at extending some features in
the Team Review center that may assist you. Currently, you can store two
different types of resources on a Team Review item, images and XMI
package exports in version 8.0. For a future build we will be looking at
potentially adding support to for a wide range of different resource
types. This will allow you to store previously external resources in the
model. They will then be more accessible plus you will be able to
discuss them with your team. Also, some other potential additions will
be the ability to see the posts relevant to you or flag a post for
others to look at.  


Best Regards,
 
(Name Removed)
Sparx Systems Pty Ltd
[email protected]
http://www.sparxsystems.com.au
« Last Edit: March 17, 2010, 01:55:54 pm by mfraser »
Fred Woolsey
Interfleet Technology Inc.

Always be ready to laugh at yourself; that way, you beat everyone else to the punch.


beginner

  • Guest
Re: Access to PDATA and other 'magic' fields
« Reply #11 on: March 17, 2010, 06:39:06 pm »
Or shorter: eventually nothing will change or not. Why didn't you ask the Oracle in Delphi?

b.

Makulik

  • EA User
  • **
  • Posts: 400
  • Karma: +0/-0
    • View Profile
Re: Access to PDATA and other 'magic' fields
« Reply #12 on: March 17, 2010, 09:39:27 pm »
[ot]
Programming Oracle in Delphi?? Stunned   ;D ...
[/ot]
Have a nice day everyone,
g.

beginner

  • Guest
Re: Access to PDATA and other 'magic' fields
« Reply #13 on: March 17, 2010, 10:30:57 pm »

Makulik

  • EA User
  • **
  • Posts: 400
  • Karma: +0/-0
    • View Profile
Re: Access to PDATA and other 'magic' fields
« Reply #14 on: March 17, 2010, 10:47:31 pm »
I know that of course, b.  (even here in the 'outer rim' we had to go to school ;) )
« Last Edit: March 17, 2010, 10:48:47 pm by Makulik »