<div dir="ltr">Hi Miroslav,<div><br></div><div>thank you for sharing your thoughts on these three ways to customize an application:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">1. Via dedicated UI forms, wizards and DSL<br></span><span style="font-size:12.8px">2. Using configuration files<br></span><span style="font-size:12.8px">3. Customizing it in application code</span></blockquote><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I believe that 1. and 2. have a somewhat symbiotic effect. Let me try to explain what I mean by this:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I think there's the act of customizing and then there is storing of this customization. The later can be a configuration file format (e.g. JSON) with DSL inside. We use PostgreSQL as our database and this can store JSON as native objects. The pure act of customization on the other side can be either writing these JSON files by hand or manipulating them using a UI.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I may be naive but I think the benefit of having a configuration file format allows for customization right from the start. A UI can be added later (that is probably the naive part).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Regards,</span></div><div><div style="font-size:12.8px">Konrad Kleine</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Software Engineer</div><div style="font-size:12.8px">Red Hat GmbH</div><div style="font-size:12.8px"><span style="font-size:13px;line-height:16.12px">Werner-von-Siemens-Ring 15</span></div><div style="font-size:12.8px"><span style="font-size:13px;line-height:16.12px">85630 Grasbrunn, </span><span style="font-size:13px;line-height:16.12px">Germany</span></div></div><div class="gmail_extra"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div><br></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jul 26, 2016 at 7:00 PM, Miroslav Hradilek <span dir="ltr"><<a href="mailto:mhradile@redhat.com" target="_blank">mhradile@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
this is the first of my emails where I will be sharing my thoughts on some design decisions that, in my opinion, are worth considering when designing ALM architecture.<br>
<br>
<br>
# User Based Setup<br>
<br>
So in most applications, and especially ones like ALM, there is a big need for customizing everything like objects, behavior etc.<br>
<br>
It is mostly done in three ways:<br>
<br>
1. Via dedicated UI forms, wizards and DSL<br>
2. Using configuration files<br>
3. Customizing it in application code<br>
<br>
<br>
I've personally had a chance to use all three ways throughout my life and I'm sure the readers are the same. All the methods have pros and cons. Some depend on licensing and their application depends on the skill set of the user.<br>
<br>
# Approaches<br>
<br>
1) UI etc<br>
This is by far the most consumable method for not very technically skilled people or people not willing to invest in learning the application. The sole configuration form is like reference documentation and configuration files combined. Even higher level of contextual configuration can be achieved by employing wizards which interact with the user until the configuration is finished.<br>
<br>
The downside to this is that it requires the application developers to burn time to code often quite complex forms. Sometimes the expression of such form is quite limited and Domain Specific Language must be defined to overcome this lack of expression. Example being the languages describing mail filters, query languages etc.<br>
<br>
After some time the user learns a lot about the application and these interfaces start to limit his/her efficiency.<br>
<br>
2) Configuration files<br>
Somewhere in between. You do not have to be a coder to configure application this way.<br>
<br>
What you have to do though, is to read quite a bit about the application and have a reference documentation at hand. This can be minimized by including the documentation inside template configuration files in form of comments. The expression is quite limited. Difficult data structures and Domain Specific Languages must be used to overcome this problem.<br>
<br>
3) Hacking the code<br>
You need to be involved a lot in the application and you have to understand it's code in order to modify it.<br>
<br>
The expression is virtually unlimited though with little effort on developers side. No config interpretation code and DSLs are necessary. This can be improved a lot by splitting the configuration part of the code from the system implementation structuring the code as a configuration file. If you include documentation in comments you have a nearly commented config file experience but you still require the user to be quite involved in the app and know at least basic data structures used in the language.<br>
<br>
The biggest downside is that the app often (not necessarily) needs to be rebuilt to perform a change. Second most severe limitation is that closed source applications would be difficult if not impossible to configure this way.<br>
<br>
# How to choose<br>
<br>
There is one important consideration, sometimes overlooked when deciding which style of configuration to employ. Apart from time money and developers personal engagement. It is the TARGET AUDIENCE.<br>
<br>
Who will be configuring which part in reality? How involved are they going to be in the application when in production? What are their use cases? Are there any security implications if I choose this over that?<br>
<br>
These are some of the questions you should consider. And please do expand on this. I'm sure you will have some more options to consider.<br>
<br>
-- <br>
Miroslav Hradilek<br>
Quality Assurance Engineer<br>
Base OS Quality Engineering<br>
<br>
Red Hat Czech, s. r. o.<br>
Purkynova 99<br>
612 45 Brno, Czech Republic<br>
<br>
_______________________________________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/almighty-public</a><br>
</blockquote></div><br></div></div>