Some interesting use cases being presented and obviously there are some "Yeah great" and some "Won't use it".
From a Product Manager's mindset, my question would have to be where does 'pixel perfect' sit in the overall strategic plan. Does this solution provide enough functionality to enable the power users to make effective use of it, or is it going to become a drain on AIM development. Is the quick and dirty offering going to fully satisfy those that use it or will it become something that then requires further enhancement to become ever 'more useable'? None of these questions are meant to be answered in this thread, they are the things that would be going through my mind if I were weighing up the options.
My concern would be that if the product roadmap for AIM includes the development of a more controllable UI development studio then working on a temporary fix will be both a distraction and an ongoing overhead that prevents that journey towards a more pure HTML editor.
Personally I try to avoid the use of HTML elements within AIM - not because I eschew HTML - but because they are clunky to use and feel like a halfway house to getting things done. I came to AIM after using Wavemaker v6 and becoming frustrated by the commercial strategy of v8 that made my costs unforecastable. Wavemaker was a good example of an HTML / Javascript (DoJo) / Spring stack that allowed HTML form development. It was attractive because it was all in one place and was completely integrated and I could work out how to manipulate everything.
I moved to AIM because it is all fully integrated forms rules and processes are all together and I don't have to worry about the database schema. That being said I miss the control of Wavemaker and I'd love to be able to have the flexibility of Wavemaker like form design inside AIM, but would never be able to use the proposed external HTML editor solution as the app I am building is 75-90% reference data or related business objects - I would imagine that unless you are creating simple information collection / presentation forms then you are likely to quickly become frustrated with the limited functionality of a form that cannot reference system data. Perhaps I have taken an overly normalised approach for my reference data.
Just because I wouldn't use it doesn't mean I don't think you should do it, but my questions would be if you do it:
Where does it go from there?
Does it become a dead branch once implemented?
Does this then start to stretch what AIM does outside the AIM ecosystem, and if so what does that mean for further development within AIM?
Does AIM start to become a back-end platform with external editors used for UI generation?
The more UI development options that become supported (assuming you don't increase your Dev team) the less focussed the development team can be on those UI options. Personally I would rather wait for a better fully integrated HTML UI studio within AIM than splintering of the dev effort or creating dead branches for expediency.
Sorry this is a long post, but I think the product strategy is a crucial element of this discussion that hasn't been covered as much as the tactical 'this would help me right now' responses.
