Stream: pascal
Topic: UI components
Jose Costa Teixeira (May 25 2018 at 13:08):
I am looking at a set of Delphi FMX UI components and I have a first "working" component - a TFHIRStringEdit. I have a design-time to list the component and a runtime library to register and implement the logic. This allows to register components and work with them in forms, but there is an issue:
Jose Costa Teixeira (May 25 2018 at 13:10):
The moment I add a TFHIRString to my component's logic, then it starts requiring the FHIR modules which ends up requiring a chain of dependencies all the way down to indy. For the runtime this is normal and expected. For the design time this does not seem ok. Anyone have experience in creating components to see what is wrong?
Jose Costa Teixeira (May 25 2018 at 13:11):
the code is in grahame's fhirtools github under reference-platform\ui\fmx.
Grahame Grieve (May 25 2018 at 17:07):
at design time, you need to manage this with packages
Grahame Grieve (May 25 2018 at 17:13):
but for a variety of reasons, you should ensure that the visual components only depend on FHIR.Base.Objects, FHIR.XVersion.Resources. FHIR.Base.Factory, and the things they use
Jose Costa Teixeira (May 25 2018 at 17:47):
yep, the moment I use fhir.base.objects, that is when it starts asking me for more and more stuff. Perhaps I missed something
Grahame Grieve (May 25 2018 at 18:31):
no. I'll check something in that helps shortly
Grahame Grieve (May 25 2018 at 18:46):
so we need to talk about UI component folders .
Grahame Grieve (May 25 2018 at 18:49):
the current code is organised so that /reference-implementation contains the base stuff need to implement a FHIR client or server
Jose Costa Teixeira (May 25 2018 at 18:49):
ok
Grahame Grieve (May 25 2018 at 18:49):
/libraries contains things that are shared between the various toolkits and servers
Grahame Grieve (May 25 2018 at 18:50):
then there's folders for the applications
Grahame Grieve (May 25 2018 at 18:50):
and some other misc stuff
Grahame Grieve (May 25 2018 at 18:50):
but the stuff you're adding now challenges that layout....
Grahame Grieve (May 25 2018 at 18:51):
I would have said to put them in /libraries/ui but they're really intended for run time
Jose Costa Teixeira (May 25 2018 at 18:54):
so we need a new place for design-time libraries?.. outside reference-platform?
Grahame Grieve (May 25 2018 at 18:55):
well, I think we should put the packages in /packages
Grahame Grieve (May 25 2018 at 18:55):
I've just created a set of packages in there that sorts out the dependency issues
Jose Costa Teixeira (May 25 2018 at 18:55):
ok let me get it
Grahame Grieve (May 25 2018 at 18:55):
.. haven
Grahame Grieve (May 25 2018 at 18:55):
haven't committed yet...
Jose Costa Teixeira (May 25 2018 at 18:56):
ok, that gives me time to lookup new word (haven) :)
Grahame Grieve (May 25 2018 at 18:56):
but the actual components are for implementing. I don't know whether to say that those things go in /reference-implementations/ui or libraries/ui, or whether we should just create a new /ui and have /fmx and /vcl under that
Grahame Grieve (May 25 2018 at 18:58):
ok pushed it. there's 3 new packages in /packages
Jose Costa Teixeira (May 25 2018 at 19:02):
vcl, fmx and core, right?
Grahame Grieve (May 25 2018 at 19:02):
for the packages, yes
Jose Costa Teixeira (May 25 2018 at 19:04):
i am noting these are both design time and runtime. won't that cause dependency issues?
Jose Costa Teixeira (May 25 2018 at 19:04):
or it's unrelated?
Grahame Grieve (May 25 2018 at 19:05):
well, my thinking here is that if you're someone who's using packages at run time, you'll make up your own package that has what you want in it. So these packages are solely to do designtime registration
Jose Costa Teixeira (May 25 2018 at 19:08):
i thought that the registration was done in the way i had it - one design time package for declaring and registering the components, the runtime containing the logic.
- but i did not have experience and obviously it was not a successful implementation.
Grahame Grieve (May 25 2018 at 19:09):
that's certainly what packages like tree view do. But it adds to the complexity, and in our case, there's complexities in the code that mean you couldn't deploy using the packages. So I didn't see why to pay the price
Grahame Grieve (May 25 2018 at 19:10):
just added a new method to the factory for you
Jose Costa Teixeira (May 25 2018 at 19:11):
oh ok. I obviously see no reason why to split packages that way, so since it prevents deployment, it's fine.
Jose Costa Teixeira (May 25 2018 at 19:15):
i see the method - thanks. If i read it well, it lists all the properties I will have in an object. Including objects as well?
Grahame Grieve (May 25 2018 at 19:17):
yes. The properties won't have any values on it, of course, but all of them will be listed
Jose Costa Teixeira (May 25 2018 at 19:18):
nice. thanks. will play with it.
Grahame Grieve (May 25 2018 at 19:19):
np
Jose Costa Teixeira (May 25 2018 at 19:19):
as for the libraries, i am getting SynEdit to see if i get the library to compile
Jose Costa Teixeira (May 25 2018 at 19:41):
ok so i got rid of SynEdit but I dont't see the connection between libraries/ui and reference-platform/ui
Grahame Grieve (May 25 2018 at 19:42):
that question is not really about packages.
Grahame Grieve (May 25 2018 at 19:42):
I've been putting all the UI components in there, but I haven't really had FHIR specific ones before.
Grahame Grieve (May 25 2018 at 19:43):
so I'm just wondering how to organise the code
Jose Costa Teixeira (May 25 2018 at 19:43):
ah.
Jose Costa Teixeira (May 25 2018 at 19:44):
fwiw, i am thinking that the fhir components will be really fhir-specific. so the FHIRStringEdit will have a property which is a TFHIRString.
Grahame Grieve (May 25 2018 at 19:44):
that's where you run into version problems
Jose Costa Teixeira (May 25 2018 at 19:44):
version as in r3/r4?
Grahame Grieve (May 25 2018 at 19:44):
because there's 3 TFHIRString right now.
Grahame Grieve (May 25 2018 at 19:44):
y.
Grahame Grieve (May 25 2018 at 19:44):
why I said to use FHIR.Base.Objects
Grahame Grieve (May 25 2018 at 19:44):
so just make it element : TFHIRElement
Jose Costa Teixeira (May 25 2018 at 19:45):
k
Jose Costa Teixeira (May 25 2018 at 19:46):
so do we need different components for different versions? it seems you are saying we shouldn't..?
Grahame Grieve (May 25 2018 at 19:46):
it would be very useful not be tied to a specific version, yes
Grahame Grieve (May 25 2018 at 19:46):
alternatively, I could say: it will be crippling to have them tied to a version
Grahame Grieve (May 25 2018 at 19:46):
the toolkit compiles for both R3 nd R4
Jose Costa Teixeira (May 25 2018 at 19:47):
another thing is that tFHIRStringEdit is pretty much the same as TFHIRURIEdit, but some content validation could be different. I am wondering whether this level of specificity is good
Grahame Grieve (May 25 2018 at 19:48):
well, you could have a single string type editor that knows what the base element is attached to is
Grahame Grieve (May 25 2018 at 19:48):
but hang on....
Jose Costa Teixeira (May 25 2018 at 19:48):
my starting point was to make those different. So this is a new approach
Jose Costa Teixeira (May 25 2018 at 19:48):
hanging on...
Grahame Grieve (May 25 2018 at 19:48):
should attach the editor to
parent : TFHIRObject
elementName : String
Grahame Grieve (May 25 2018 at 19:48):
not directly to the elemnt itself?
Jose Costa Teixeira (May 25 2018 at 19:50):
hmmm... TFHIRObject would be the next parent object, or the top-level object?
Jose Costa Teixeira (May 25 2018 at 19:50):
(e.g. if we have a bundle of patients with addresses, where is the editor attached to?)
Jose Costa Teixeira (May 25 2018 at 19:51):
i thought it might be easier to have it attaced to the element. but must think of how it would work
Grahame Grieve (May 25 2018 at 19:53):
the problem is what to do if the element doesn't exist
Jose Costa Teixeira (May 25 2018 at 19:53):
and what if the element has multiple cardinality? what is the solution for that?
Grahame Grieve (May 25 2018 at 19:53):
I was about to say that
Jose Costa Teixeira (May 25 2018 at 19:55):
i was hoping to leave that problem in the parking lot for now.... but let's go:
for now i am thinking that the editor should be attached to the element. The element dies, the editor vanishes. The UI says "add another one of these elements", the Editor gets created.
Grahame Grieve (May 25 2018 at 19:55):
isn't that a bit of an odd UI to 0..1 elements?
Jose Costa Teixeira (May 25 2018 at 19:56):
this is why i wanted the method to list all possible objects in an object, so that i could programmatically add the buttons on top of the toolkit.
Jose Costa Teixeira (May 25 2018 at 19:56):
right. I had optional objects covered, but not optional elements
Grahame Grieve (May 25 2018 at 19:57):
maybe primitive type editors can be attached to either an element or a parent+name?
Jose Costa Teixeira (May 25 2018 at 19:58):
I see the problem. It is "normal" that he editor is there even if the elemnent doesn't
Jose Costa Teixeira (May 25 2018 at 19:59):
actually in the Scenario editor i have the editor anyway. It is assigned to nil, or it is assigned to an element.
Jose Costa Teixeira (May 25 2018 at 20:00):
Actually at this moment it creates an object the moment the user starts entering text.
Grahame Grieve (May 25 2018 at 20:01):
but where does the object go when they're done?
Jose Costa Teixeira (May 25 2018 at 20:01):
what is "when they are done"?
Jose Costa Teixeira (May 25 2018 at 20:01):
the object is attached to the parent object.
Grahame Grieve (May 25 2018 at 20:01):
how does that happen?
Jose Costa Teixeira (May 25 2018 at 20:03):
jsut to capture this idea:
so one option for cardinalities (first time I m thinking of this) could be that the editor always exists, and gets assigned to an object when content is added. if the element has 1..x then the object must always exist and we find a way to show it. Could be a * next to it. If the element is x..* then we can have a "add another here" button next to it.
Jose Costa Teixeira (May 25 2018 at 20:04):
the FHIRStringEdit does that. Here's how it works:
Jose Costa Teixeira (May 25 2018 at 20:06):
FHIRStringEdit has a property (pointer) TFHIRString.
Jose Costa Teixeira (May 25 2018 at 20:07):
and a get and a set for that property.
Jose Costa Teixeira (May 25 2018 at 20:08):
Setting the string object forces the Edit to update the text.
Jose Costa Teixeira (May 25 2018 at 20:09):
and then there is a method i had to create, called "associate".
Jose Costa Teixeira (May 25 2018 at 20:09):
in the main code, i simply do this:
TFHIRExampleScenario(obj).nameElement:= edit5.associate(TFHIRExampleScenario(obj).nameElement);
Grahame Grieve (May 25 2018 at 20:10):
so what happens if nameElement is nil?
Jose Costa Teixeira (May 25 2018 at 20:10):
normally i can do
edit5.associate(TFHIRExampleScenario(obj).nameElement);
Jose Costa Teixeira (May 25 2018 at 20:11):
but _currently_ whenever associating it , i will force the creation of an object. hence the function returning the value to the object
Jose Costa Teixeira (May 25 2018 at 20:11):
function TFHIRStringEdit.associate(AValue: TFHIRString): TFHIRString;
begin
if fFHIRString = nil then
begin
fFHIRString := TFHIRString.Create;
text:='';
end
else begin
fFHIRString := AValue;
text:=fFHIRString.value;
end;
result:=fFhirString;
end;
Jose Costa Teixeira (May 25 2018 at 20:11):
so if aValue is nil, it creates one and returns it.
Jose Costa Teixeira (May 25 2018 at 20:14):
i tested it. I don't find it elegant but it works and the resource stays "clean" when i export (i.e. it does not create thinks like <name value=""/>
Grahame Grieve (May 25 2018 at 20:15):
wouldn't this be better then:
procedure associate(owner : TFHIRObject; name : String); begin prop := owner.getPropertyValue(name); if not prop.hasValue() then begin element := Factory.makebyname(typeName); prop.setValue(name, element); end else element := prop.values[0]; end;
Grahame Grieve (May 25 2018 at 20:16):
but it still leaves open the question of what happens if the user never enters anything....
Jose Costa Teixeira (May 25 2018 at 20:18):
looking at this: what if you want to create another patient.name.given?
Grahame Grieve (May 25 2018 at 20:21):
it would not be appropriate to use this form of associate for an element with cardinality >1
Jose Costa Teixeira (May 25 2018 at 20:23):
this form = your code or my code?
Grahame Grieve (May 25 2018 at 20:23):
my code
Jose Costa Teixeira (May 25 2018 at 20:25):
in my code, and assuming that I can create UI elements at runtime (which I can), the entire "who is owning how many of these" is left to the object
I create anothe element in an object -> I create an editor for that element.
Grahame Grieve (May 25 2018 at 20:38):
well, I don't follow but maybe you should develop it further before we discuss more
Jose Costa Teixeira (May 25 2018 at 20:38):
so the pieces of the puzzle I imagine are:
- From an object, determine what are the objects in it (thanks for the factory method).
- When displaying the object, put a button in the UI for each sub-objects (tested, seems to work).
- When displaying the same object, also put an editor for each element. If element is nil, editor is empty and vice versa.
- (Need to figure out the best way to hadle cardinalities in the UI and in the object but my startin approach could work, no?)
- Need to figure out how to deal with bindings
Jose Costa Teixeira (May 25 2018 at 20:39):
ok i will play a bit. The issue with the library was the thing preventing me from sharing.
Jose Costa Teixeira (May 25 2018 at 20:40):
so, and since i did not get that:
in the packages you sent, where would I add my TFHIRStringEdit?
Grahame Grieve (May 25 2018 at 20:40):
to the FMX package
Jose Costa Teixeira (May 25 2018 at 20:41):
or there is still some digging before we reach that point?
Grahame Grieve (May 25 2018 at 20:41):
and if it wants to add any FHIR units to the FMX package, we need to talk about each unit
Jose Costa Teixeira (May 25 2018 at 20:42):
so i guess you advise me to get rid of the TFHIRString property and use a TFHIRElement instead, right?
Grahame Grieve (May 25 2018 at 20:43):
yes. it's a little more work now to make it entirely metadata driven, but it will be a lot better in the long run
Jose Costa Teixeira (May 25 2018 at 20:46):
tfhirelement is also declared in FHIR.R4.types, no?
Grahame Grieve (May 25 2018 at 20:47):
oh. TFHIRObject not TFHIRElement. sorry
Jose Costa Teixeira (May 25 2018 at 20:48):
ah i remember being there...
Jose Costa Teixeira (May 25 2018 at 20:48):
it did not seem "a little" more work. :)
Grahame Grieve (May 25 2018 at 20:48):
lol. we can add helper methods to the Base.Objects unit
Jose Costa Teixeira (May 25 2018 at 20:49):
i will try and go for it.
Grahame Grieve (May 25 2018 at 20:49):
great
Jose Costa Teixeira (May 25 2018 at 20:49):
hope it rains tomorrow
Grahame Grieve (May 25 2018 at 20:49):
oh?
Jose Costa Teixeira (May 25 2018 at 20:49):
then i have an excuse to stay in. :)
Grahame Grieve (May 25 2018 at 20:49):
lol
Jose Costa Teixeira (May 25 2018 at 20:50):
i actually did manage to run this thing, but i had to use a trick.
fwiw: i made a tthirStringEdit but commented out the TFHIRString bit. Then I could install the component and place it in the form
Jose Costa Teixeira (May 25 2018 at 20:51):
then i added the rest to the code of the component and when it rebuilt, it worked.
Jose Costa Teixeira (May 25 2018 at 20:52):
so next adventure, get the TFHIRStringEdit installed in the FMX library
Jose Costa Teixeira (May 25 2018 at 20:53):
trying to remember the difficulty - perhaps tfhirString has a .value. But TFHIRObject doesn't. I think it was somethign like this that made me go back to specific classes
Jose Costa Teixeira (May 25 2018 at 20:54):
i think that was it.
Jose Costa Teixeira (May 25 2018 at 20:54):
i could not do typecasting, because, well, the moment I cast something as a tfhirstring, then i need to use R4.types..
Grahame Grieve (May 25 2018 at 20:54):
yes you have to use .getPropertyValue
Jose Costa Teixeira (May 25 2018 at 20:55):
aaaaah nice!
Jose Costa Teixeira (May 25 2018 at 20:55):
and what is the propname?
Jose Costa Teixeira (May 25 2018 at 20:56):
i think that may end up being a new property in my object, right?
Grahame Grieve (May 25 2018 at 20:57):
for primitives it's always 'value'
Jose Costa Teixeira (May 25 2018 at 20:58):
ok, so
fFHIRObject.getPropertyValue('value')
should work, right?
Grahame Grieve (May 25 2018 at 21:01):
yes
Jose Costa Teixeira (May 25 2018 at 21:01):
and how do i set the property value if i have this
setPropertyValue(propname: string; propValue: TFHIRObject)
?
how can i pass a value to propvalue? sorry if it's trivial but i don't see it
Grahame Grieve (May 25 2018 at 21:01):
you need a factory to create it
Grahame Grieve (May 25 2018 at 21:01):
so what your resource will need is a factory
Jose Costa Teixeira (May 25 2018 at 21:10):
mind = blown
Jose Costa Teixeira (May 25 2018 at 21:12):
any advice / pseudo-code to know how that is done would be helpful.
Grahame Grieve (May 25 2018 at 21:13):
factory?
Jose Costa Teixeira (May 25 2018 at 21:14):
i will catch up on reading on factories. I will need that anyway. but any light on what i could end up with, inside my component?
Jose Costa Teixeira (May 25 2018 at 21:14):
my editor will have a tfhirObject, and i will re-route the editor's onChange method to update the object's property.
Jose Costa Teixeira (May 25 2018 at 21:15):
do i create an object there? I thought that is what factory was for..
Grahame Grieve (May 25 2018 at 21:16):
you'd just have a property Factory : TFHIRFactory which has to be assigned at run time nd then you use that
Jose Costa Teixeira (May 25 2018 at 21:20):
but the factory is used to create an object, or am i missing the point?
Grahame Grieve (May 25 2018 at 21:20):
yes you always create via the factory
Jose Costa Teixeira (May 25 2018 at 21:20):
i don't see the relation between the factory and the TFHIROPbject
Grahame Grieve (May 25 2018 at 21:21):
you want to create a fhir string:
var element := Factory.makeByName('string');
Grahame Grieve (May 25 2018 at 21:22):
that's the same as TFHIRString.create but you'll get whatever is appropriate for the version
Jose Costa Teixeira (May 25 2018 at 21:22):
ah, ok.
Jose Costa Teixeira (May 25 2018 at 21:23):
and for setting element.value?
Jose Costa Teixeira (May 25 2018 at 21:24):
(when the user changes the edit, i must update the object)
Jose Costa Teixeira (May 25 2018 at 21:24):
this is the part i am missing. perhaps it's clear but it's late and i may be missing the obvious
Grahame Grieve (May 25 2018 at 21:26):
no I've just discovered it's not obvious to me either. let me investigate
Jose Costa Teixeira (May 25 2018 at 21:26):
ok thanks
Jose Costa Teixeira (May 25 2018 at 21:26):
i will catch up tomorrow then.
Jose Costa Teixeira (May 25 2018 at 21:26):
THANK YOU for this.
Grahame Grieve (May 25 2018 at 21:27):
np. Im glad you're wokring on it
Jose Costa Teixeira (May 25 2018 at 21:37):
hold that thought until I ask what is the UI editor for a Markdown type ;-)
Grahame Grieve (May 25 2018 at 21:40):
I don't have an FMX editor for that
Jose Costa Teixeira (May 26 2018 at 07:17):
MyFactory.createPropertyList('ExampleScenario',false) throws "the implementation of TFHIRFactory.makeByName should never be called"
Grahame Grieve (May 26 2018 at 07:47):
you have to create factory for the right version
Jose Costa Teixeira (May 26 2018 at 21:36):
almost there.
Jose Costa Teixeira (May 26 2018 at 21:36):
How can i create a resource given a name? is there a factory for that?
Jose Costa Teixeira (May 26 2018 at 21:37):
e.g.
myresource:=xxxxcreate('Observation');
Grahame Grieve (May 26 2018 at 21:37):
factory.makeByName
Jose Costa Teixeira (May 26 2018 at 21:37):
thanks
Jose Costa Teixeira (May 26 2018 at 21:43):
ok so one concept is working:
Create UI components programmatically given the resource type - i only do parameters that strings (Tedit) or markdowns (tmemo) at the moment.
Jose Costa Teixeira (May 26 2018 at 21:44):
next i will go on to link those components to the elements (e.g. the TFHIRStringEdit) and see how that goes.
Jose Costa Teixeira (May 26 2018 at 22:11):
Jose Costa Teixeira (May 28 2018 at 05:31):
Here's what I realized:
Building the panel in the code like that is ok, but gets messy when i have to associate each component with its FHIRObject. So i'd want to make a composite component - TFHIRStringEdit should not be a descendant of TEdit, but should be a composite with a Label, an Edit, a Button.
Grahame Grieve (May 28 2018 at 05:31):
good because I think the same.
Grahame Grieve (May 28 2018 at 05:32):
and help text, and possibly a translations button for editing translations, or other extensions depending on setting
Jose Costa Teixeira (May 28 2018 at 05:32):
The procedure I have creates all the "possibly required" objects. perhaps this should be changed.
Jose Costa Teixeira (May 28 2018 at 05:33):
So when we have a resource, either
1. We build all possible object panels, and then associate object - UI whenever the object is selected. E.g. selecting a patient.contact updates the panel “contact” with the data of the current contact.
or
2. We build one panel for each object instance in the resource. Every time we add a contact with the button, we create a similar panel. So if we have 2 contacts for a patient, we have 2 panels and we display each when needed.
Jose Costa Teixeira (May 28 2018 at 05:35):
I am lazy so I would lean towards 2.
Jose Costa Teixeira (May 28 2018 at 05:37):
but it is just because it's too far to think about it. I do not yet know which one would actually make more sense.
Jose Costa Teixeira (May 28 2018 at 05:37):
maybe 1 is better if the UI panel has a ".load" or ".associate" method
Jose Costa Teixeira (May 28 2018 at 22:13):
while i still did not make the extensions and translations, I have a composite component that has a label (showing the FHIRPropertyName) and a button (which has a hint and whose purpose, tomorrow, will be to add another line and another tedit. Not sure how that will work but i will look at the methods and will probably figure it out.
Jose Costa Teixeira (May 28 2018 at 22:13):
Jose Costa Teixeira (May 28 2018 at 22:14):
(those are 2 components in the diagram btw. The multiple cardinality is not implemented.)
Jose Costa Teixeira (May 28 2018 at 22:14):
first TFHIRStringEdit has Multiple=true, second has Multiple=false;
Jose Costa Teixeira (May 28 2018 at 22:15):
this will probably need to evolve when we look at slicing, but for now i'd want to move to the next stuff.
Jose Costa Teixeira (May 28 2018 at 22:18):
the thing I am unable to do still is how to add the FHIR classes, e.g. TFHIRString. The moment I do, there is the torrent of dependencies that i cannot manage at design time.
Grahame Grieve (May 29 2018 at 19:56):
no you can't use them
Grahame Grieve (May 29 2018 at 19:57):
we have to figure out how to do what you want to do that makes you want to use them
Jose Costa Teixeira (May 29 2018 at 20:22):
ok, if useful i have draft component (not using the FHIR classes) and i can put it somewhere with a small project to test it.
Jose Costa Teixeira (May 29 2018 at 20:23):
current idea is to associate each UI component with a FHIR object.
Jose Costa Teixeira (May 29 2018 at 21:47):
tomorrow i will try to get one working app that uses my draft component, and show where my needs are.
Grahame Grieve (May 29 2018 at 21:55):
ok
Jose Costa Teixeira (May 30 2018 at 22:44):
i put a few things up
- FHIRComponents.bpl is the package that contains one component in FHIR.FMX.Ctrls.pas (WIP).
- UI_Creator is the app that generates UI from the resource name.
- FHIRComponentTest is the app to show how these should be "glued" together.
Jose Costa Teixeira (May 30 2018 at 22:47):
The challenge (as good as i can explain it at this time) is seen at TForm1.FHIRStringEdit1Change:
for this component (i.e. for each TFHIRStringEdit) i use code like "pat.identifierList".
Jose Costa Teixeira (May 30 2018 at 22:49):
i would like such code to be hidden in the component itself, so that i don't have to recode for every resource
Jose Costa Teixeira (May 30 2018 at 22:54):
so if I would associate each component that i create with a property, and then inside the component i would update the FHIR property.
this was possible using FHIR object types in the component definition. Without that, i don't know how to achieve the same.
Grahame Grieve (May 31 2018 at 21:16):
what happened to Uix.Controls? why did you remove a whole heap of code out of it?
Jose Costa Teixeira (May 31 2018 at 23:34):
oh sorry, my mistake.
Jose Costa Teixeira (May 31 2018 at 23:34):
i was trying to get it to build without having the needed components so i changed it. Then i think i committed that by mistake. My apologies
Jose Costa Teixeira (May 31 2018 at 23:36):
i was going to restore but it seems you already have done so, right?
thanks
Grahame Grieve (May 31 2018 at 23:36):
yes i restored it
Jose Costa Teixeira (May 31 2018 at 23:39):
thanks
Grahame Grieve (May 31 2018 at 23:39):
no problems
Grahame Grieve (Jun 01 2018 at 01:07):
ok. catching up.... note sure what this question means: "so if I would associate each component that i create with a property, and then inside the component i would update the FHIR property.
this was possible using FHIR object types in the component definition"
Jose Costa Teixeira (Jun 01 2018 at 07:56):
(my build is complaining about a missing FHIR.Version.Context.pas)
Jose Costa Teixeira (Jun 01 2018 at 07:57):
on associating a component with a property:
Grahame Grieve (Jun 01 2018 at 07:58):
so you need to add a unit alias: FHIR.Version.Context=FHIR.Rx.Context where X is the version you are compiling for
Jose Costa Teixeira (Jun 01 2018 at 07:59):
in my small component demo app, i get the TFHIRStringEdit's onChange event, and then put the value of the text in pat.identifier.
Grahame Grieve (Jun 01 2018 at 08:01):
... ok...?
Jose Costa Teixeira (Jun 01 2018 at 08:01):
the idea behind making this a generic UI client is to avoid manually coding things like "pat.identifier".
Jose Costa Teixeira (Jun 01 2018 at 08:02):
if when generating the UI I could say "for each property Px in this resource, create a UI component AND let that component know that when it is updated, it is updating property Px",
Jose Costa Teixeira (Jun 01 2018 at 08:03):
then i could avoid that code.
Jose Costa Teixeira (Jun 01 2018 at 08:05):
what I had before (but did not allow installing the UI component package) was exactly that:
I create a UI component instance, and then said "from now, associate this instance with property Px.
Jose Costa Teixeira (Jun 01 2018 at 08:07):
and after that, i did not need to type any more references to FHIR objects.
Grahame Grieve (Jun 01 2018 at 09:27):
umm ok. it's not crystal clear what your asking for?
Jose Costa Teixeira (Jun 01 2018 at 09:28):
yeah, there is one design decision i haven't taken yet, and probably that is making things fuzzy
Jose Costa Teixeira (Jun 01 2018 at 09:29):
question: did you install the bpl i had made in the FMX_FHIR_UI folder? It's draft..
Grahame Grieve (Jun 01 2018 at 09:30):
no i haven't installed it yet
Jose Costa Teixeira (Jun 01 2018 at 09:31):
cause I just changed the component to show how i see it working
Jose Costa Teixeira (Jun 01 2018 at 09:32):
i.e. to show why "this concept" could work if I could use FHIR classes - the example App shows what is "this concept".
Jose Costa Teixeira (Jun 01 2018 at 09:40):
and now that i restart my ide i see it crashes... let me figure out what is the issue
Jose Costa Teixeira (Jun 03 2018 at 06:54):
i pushed some code to show the concept i am after.
Jose Costa Teixeira (Jun 03 2018 at 06:57):
the idea is:
Jose Costa Teixeira (Jun 03 2018 at 07:00):
in FHIRComponentTest, i show how I use a TFHIRStringEdit:
simply associate it with an FHIR element. in the example this is done by
res.nameElement:=FHIRStringEdit1.associate(res.nameElement);
Jose Costa Teixeira (Jun 03 2018 at 07:03):
this is now (almost) working because I could tweak it by first installing the component without using FHIR classes, and only after that add the FHIR classes.
Jose Costa Teixeira (Jun 03 2018 at 07:04):
so that is WIP 1: how to allow installing one component to which we can forward a FHIR class.
Jose Costa Teixeira (Jun 03 2018 at 07:13):
the second WIP is to use this in the automated UI generator:
the UI generator now creates UI components for each FHIR property, so we can have something like:
Jose Costa Teixeira (Jun 03 2018 at 07:14):
PL:= ffactory.createPropertyList(st,true) ; for i := 0 to PL.Count-1 do if PL.Properties[i].Type_ = 'string' then begin edt := TFHIRStringEdit.Create(parentframe); currentProperty:=edt.associate(currentProperty); end;
Jose Costa Teixeira (Jun 03 2018 at 07:15):
(the above is simplified code)
Jose Costa Teixeira (Jun 03 2018 at 07:16):
and the last line i still have to figure out: how to point to the CurrentProperty object.
Jose Costa Teixeira (Jun 03 2018 at 07:17):
when that is done, i can create a UI that allows editing whatever properties the factory tells it to.
Jose Costa Teixeira (Jun 03 2018 at 07:25):
(the "+" button in the component still needs further thought. the idea is that if the FHIR object is a list, we forward that list to the component, and the component does the rest)
Jose Costa Teixeira (Jun 05 2018 at 14:15):
How can i iterate through the actual properties of a resource instance?
Jose Costa Teixeira (Jun 05 2018 at 14:25):
The CreatePropertyList allows me to create UI components for each possible property given the resource type. That works well.
Now I am looking to set each property of the resource instance.
Jose Costa Teixeira (Jun 05 2018 at 14:31):
a test case for what i need to do could be
"create an instance of a resource type Patient, set the value of each property of type 'identifier' to 'nothing' ".
Grahame Grieve (Jun 05 2018 at 18:43):
you can ask each object for it's property list
Jose Costa Teixeira (Jun 05 2018 at 19:45):
Ok and that also gets me the properties that are not set yet? Or only those that have already values assigned?
Grahame Grieve (Jun 06 2018 at 03:16):
no it gives you all, some of them won't have value s
Jose Costa Teixeira (Jun 05 2019 at 19:13):
exactly one year ago i was working on this, but I will need help to see if this makes sense to recover (i did it for fun and games, but it would end up being a generic FHIR resource editor):
I have a rough draft of something that allows me to programmatically generate a UI, and i got stuck in one thing - after I programmatically create a TEdit, i need to associate that TEdit content to an resource element.
If I have a codeableConcept, this would create 2 groups of TEdits (coding + string) , which would be associated with the elements.
Jose Costa Teixeira (Jun 05 2019 at 19:14):
every control would have its onExit which would do ThisElement.text=TEdit.text, etc.
Jose Costa Teixeira (Jun 05 2019 at 19:18):
This is low priority, (ExampleScenario and IG Editor are more important) but i saw that
a) there seems to be no tool for editing resources
b) at some point we will grow tired of making xxxEditors
c) this could be fun not only for editing xxxEditors from the core spec but from profiles
Grahame Grieve (Jun 06 2019 at 05:34):
I think it makes much more sense to do that in javascript/html/electron
Jose Costa Teixeira (Jun 06 2019 at 07:43):
ok, then as soon as I get someone looking at Javascript, i can share some ideas, but I don't pursue it.
Grahame Grieve (Jun 06 2019 at 10:03):
yes that's the downside of doing it in javascript....
Last updated: Apr 12 2022 at 19:14 UTC