Initial presentation UI implementation.

[kwilliams1987]

Implementation for #4.

UI Elements are now generated using metadata attributes instead of display templates.

[malware-dev]

Can you please explain your thought process with this? Primarily, why the need for a separate metadata class? Why the object properties?

[kwilliams1987]

The use of MetadataType classes is one borrowed from Entity Framework.

It allows us to keep the UI decorator attributes out of the Shared Project (removing the need to have MDK-SE projects include references to the additional assemblies).

The alternative would mean needing to overwrite and re-implement every single property to add the UI attributes.

The use of object as the property type is simply common practice for metadata classes as the datatype is irrelevant. Only the property name is used to match the metadata to it's target property.

The most important goal is to keep the MDK-Mockups shared project purely for the (as portable as possible) mockup functionality.

Anything additional required by MDK-UI to implement additional UI functionality should be part of MDK-UI, the metadata classes are the perfect tool for this use case.

[malware-dev]

I see. I don't like the separation, it feels overcomplicated, but I understand the reasoning. I originally figured the attributes would be part of the definition of the mockups themselves and thus part of the shared project, I don't see the harm.

[kwilliams1987]

Harm is a big work, however some of the meta types (RangeAttribute for example) are from assemblies not whitelisted by SE (and thus included by default in the MDK-SE template).

I think it would be counter-intuitive to require anyone using MDK-SE to include a reference to System.ComponentModel.DataAnnotations.dll just so if they decide to use the mockup shared project it can still compile... even though nothing in the System.ComponentModel.DataAnnotations namespace is whitelisted.

The other option would be to have to make custom versions of the attributes in the shared project (with the same .debug.cs file caveats).

[malware-dev]

I was kinda hoping that adding the mockup systems to a project would be adding a nuget package, making such issues... well, a non-issue.

[malware-dev]

I dunno. This isn't anything I feel strongly about. It was just the basic thoughts and ideas I had when originally designing this project.

[kwilliams1987]

Personally I still feel it makes sense to keep UI markup in the UI project and not clutter up the mockups, regardless how the mockup package is delivered, however it's not something I'd fight tooth and nail for.

I used the practice I'm used to for achieving this, but there's little issue for me in moving the meta data attributes to the mockup project.

Do you also feel the IMockupRuntimeProvider should be in the Mockups shared project?

[malware-dev]

Not really. The basic reasoning I have is that with your approach, making a mockup and making it support UI is two separate things. In my opinion, defining a mockup and its UI properties are part of the same job, and should be possible to do in one go, ([add] and should even be a requirement [/add]) without having to reference and modify multiple projects. Separation is all well and good, but it's not always for the best. And these are just attributes, suggestions. They're not actually locked to the UI project - but any kind of project that might want to do some kind of presentation on them. Meaning - having the attributes available directly for the mockups is one thing. Adding any specific interface or code or anything like that - is something completely different.

You've done a lot of work on this project. I'll defer to your judgement on this, I just wanted to state my opinion and the reasoning for it.

[kwilliams1987]

They're not actually locked to the UI project - but any kind of project that might want to do some kind of presentation on them. Meaning - having the attributes available directly for the mockups is one thing. Adding any specific interface or code or anything like that - is something completely different.

You make a good argument here, having the descriptive attributes available to any project which could consume them would be a useful feature.

I'll move the attributes into the MDK-Mockups project, and leave the specific mockup implementation code (IMockupRuntimeProvider) in the MDK-UI.

[malware-dev]

Looks good to me!

[malware-dev]

These are obsolete and should be marked as such

[kwilliams1987]

Will obsolete those methods and merge.

…

On Wed, 15 May 2019, 11:58 Malware, ***@***.***> wrote: ***@***.**** approved this pull request. Looks good to me! ------------------------------ In Mockups/Blocks/MockTextPanel.debug.cs <#19 (comment)> : > @@ -179,9 +165,51 @@ public virtual void ReadPublicText(StringBuilder buffer, bool append = false) public virtual void RemoveImageFromSelection(string id, bool removeDuplicates = false) => _surface.RemoveImageFromSelection(id, removeDuplicates); + public virtual bool WritePublicText(string value, bool append = false) These are obsolete and should be marked as such — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#19?email_source=notifications&email_token=AAUZMPADLJWKNFT6KSYR72LPVPNDZA5CNFSM4HMQB3BKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOBYVVN7I#pullrequestreview-237721341>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUZMPDSDSLFJHJKLAM5GSLPVPNDZANCNFSM4HMQB3BA> .