Hi Peter,

Here's an idea I had this morning.

User story: I use components all the time, but sometimes I cannot create the component as I want to. Say, for example, you have a dialog which is used over and over again. The title however can be different in several instances however (for example: add contact, edit contact, details of contact xxx, ...). Since this title is changed frequently I cannot create a component for the dialog. And thus, if I want to change the layout of it afterwards I need to do it several times.

There might be an easy way of getting this to work. You have implemented some parameters like ${screen-name} already. If you would be able to create your own screen properties and be able to reference them in the component this would make a big difference. A small thing that can increase productivity significantly. So, in the component you would say something like ${dialog-title} and your value would show in the instance. You could create custom properties for files just like you can for widgets now. If the property is not found just show nothing. It would be really useful if you could combine several parameters. Imagine this component for example: Hello ${login-name}, {admin-link1} {admin-link2} This would show your login name and if you are an admin 2 other links as well.

Just an idea, but I would love to hear what you think about this one.

Hi Wim,

I know exactly what you are talking about and I intend to improve components to support your use case. Your idea with properties is interesting but I have something simpler in mind. Well, simpler for the user, but technically more complex.

Basically I'd like to let users double-click on a component and "enter inside". Then the contents of the component can be edited in a natural way. Changing texts and other properties will override the original. Behind the scenes the editor will track changes and only store the differences in XML. So in your example, changing the dialog's title will store this title locally and it will override the original title. The rest of the component will still be inherited from the source screen file.

My first step in this direction is to let users edit groups since editing groups and components is visually very similar. I have a version with this feature in beta-testing. See this discussion for more information and if you wish to give a helping hand: https://wireframesketcher.com/forum/topic/25639/various_asset_related_requests

That's even better. I followed the discussion you mentioned already and noticed that great things are about to expect in the upcoming release.

Great work Peter!

Hi Wim,

I just released a new version that brings "overriding component properties" functionality:

http://wireframesketcher.com/blog/2011-10-03-overriding-component-properties-font-size-wiki-syntax.html

I'd love to have your feedback!

Thanks Peter! That's fast! I have a project in the upcoming weeks where I can definitely use this feature. I'll let you know my thoughts on it.