How about REAL Styles for diagram items?

[Paolo F Cantoni]

All my "farting about" with local styles in the last couple of days has highlighted my initial dissatisfaction when "styles" were first introduced.  I thought they'd be like Office "Styles" - able to be attached to items which would automatically re-render when the style changed.

Since the styles are stored in the DB anyway (in table: t_trxtypes), when we apply a "Style" to an item, why not just create an entry in the appropriate "style" column in the row that references the named style?  This would replace the list of individual stylistic items in the column and allow "late binding" to the actual style in use for a particular circumstance!

We can therefore update the style once and get all the items updated.

We can add styles to the Import/Export Reference Data  (I thought I saw somewhere where that was possible, but I appear to be mistaken).  Consequently, the metadata for rendering would remain the same (style=xxxx) but the actual manifestation could be on a repository by repository basis.

Consistency of rendering via identified Styles are a REALLY important way of communicating with the users.  Increasingly, I'm creating models and diagrams intended to be used by domain staff not IT people.

Lastly, it would be really cool if the stereotype rendering could access them also...

Submitted.

Thoughts? Votes?
Paolo

[«Midnight»]

I'm not too sure about this one Paolo,

IMO you are quite correct across the board. But you are also getting dangerously close to suggesting a rewrite, or at least an extension, of the shape script facility. I've been nudging (gently and otherwise) Sparx on this since they first appeared in beta form. I note that the scripting language version has not evolved.

[Note: When I refer to the "shape script facility" in this post I mean any and all features within EA that affect how custom rendering can be controlled by users and coders.]

While there have been some minor tweaks to shape scripts themselves this falls well short of the degree of change that is needed. What we need is to 'go out and come back in again' here. The scripting approach can probably be made to work, but there has to be some serious groundwork done, and a robust language platform built upon this foundation. It the scripts must have a two-way connection to the API.

Sadly, 0.02 CAD doesn't seem to be worth much these days...

[Paolo F Cantoni]

I'm not too sure about this one Paolo,

IMO you are quite correct across the board. But you are also getting dangerously close to suggesting a rewrite, or at least an extension, of the shape script facility. I've been nudging (gently and otherwise) Sparx on this since they first appeared in beta form. I note that the scripting language version has not evolved.

[size=18]...[/size]

I should have been a bit clearer.  The reference to shapescripts was almost a throwaway.  (and as usual throwaway are what get us into...)

Firstly, the issue of styles is principally for manual operation and application.  I want to be able to define the style (which I now pretty much can - some minor consistency tweaks are needed but the technology is OK).

Next we need a mechanism to associate the style with the item - but not as present (by placing an instance of the style definition - as specified at the time!), but by placing an indirect reference to the style (style=<name>).  This allows the item to reference the current manifestation of the style.  Perhaps, an option could be provided to place a snapshot of the style (as at present).

Obviously, as the style definition changes, the items would be re-rendered.

Now, shapescripts are behavioural - so style definition (declarative) shouldn't be part of that.  I'm just proposing a setstyle(<name>) method to set the fill,border and font colours and pen width (as though I'd issued the equivalent setfillcolor(), setpen() commands).

Style definition would have to be via an additional API call.

I really don't see how it's a major step from the existing - since the styles are already stored in the DB.  I'll even wait for the import export  if I can get the actual application of the dynamic style sooner.

Paolo

[«Midnight»]

Yes, we're in focus now.

[Paolo F Cantoni]

Yes, we're in focus now.

That's good!

(Because today Sparx accepted the feature request...)

So if anyone has additional functionality that they think would be useful in the same area, we might as well let our thoughts be known...

Paolo