[Opa] Enterprise, HTML, Authentication, MVC and more

Alok Menghrajani alok.menghrajani at gmail.com
Wed Jan 30 18:25:02 UTC 2013


On Wed, Jan 30, 2013 at 9:48 AM, TJ <opa at iam.tj> wrote:

> I'm currently evaluating Opa's suitability for developing web-based
> applications for medium and large Enterprises with well-defined formal
> development methodologies and processes. I wonder if MLstate could address
> the following observations and questions. Thanks in advance.
>
> Some of the attractive features are:
>
>  * type-checking
>  * single language on client and server
>  * inference of client server separation
>  * harnessing existing platforms and libraries (e.g. node.js, jquery)
>  * seems to offer considerable reduction of development complexity for
> client-server applications.
>
> During my early research I've identified some key concerns that despite
> extensive efforts I've been unable to find answers to.
>
> 1. What seems to be lacking is comprehensive documentation for much of the
> API and some parts of the language. CONTRIBUTING.md stresses the importance
> of documenting the
> code to support opadoc but the existing code-base seems to ignore that -
> not a good example, and needlessly puts the new-entry barrier much higher
> than
> it needs to be. See, for example, stdlib.core.xhtml.dom_element and
> stdlib.core.xhtml.Dom.get_text.
>
> Note: CONTRIBUTING.md says "For an example of documentation, see
> DOCUMENTING, in this directory, or see all the existing documentation." ...
> but there
> is no DOCUMENTING file.
>
> The language definition is hazy. For operator precedence "The priority and
> associativity of the operators is based on the leading characters of the
> operator" seems somewhat obtuse and doesn't clearly
> define how custom operator precedence is determined - especially if their
> leading characters aren't in the table shown in the core documentation. It
> also doesn't make clear what \| is.
>
> These omissions and inconsistencies quickly develop a lack of confidence
> since they damage the authority such documentation should have.
>

I think the Opa community can really make a difference here. If we improve
the documentation as we build web apps, we'll end up with really good &
useful documentation!

8. Several external service APIs are baked into the standard library. What
> happens when those APIs are changed? Production deployments may be left
> hanging waiting for MLState
> to update the stdlib implementation. This is a major risk for any
> organisation deploying Opa especially where changes have to be internally
> reviewed and approved before being
> deployed to production.
>

The stdlib is open source. If an external API you really care about
changes, you can fix the code. This issue is going to exist with any
framework.


> 9. Views. In all the example code the View is Opa source-code with a mix
> of functional language and X(H)TML text strings. What concerns me in
> particular is
> this hard-coding of the HTML elements. What I expected to see was a clean
> separation of (X)HTML view templates from code, with insertion of dynamic
> elements and content through
> utilising the DOM (client or server-side, depending on context). E.g:
>
> <html>
>  <head>
>   <title id="custom_title"></title>
>  </head>
>  <body>
>   <h1 id="custom_title_page"></h1>
>  </body>
> </html>
>
> And in the view source-code something along the lines of:
>
> custom_title = "Hello World Example";
> document.title = custom_title;
> document.getElementById('custom_title_page').innerHTML = custom_title;
>

This is a bad idea. You are going to end up with a page that will be
mostly empty (or broken) until the last piece of js loads to "fix" the
page.

In general you should not care how Opa transforms your code in
html/js/css. As long as it works, you should be happy.


> Instead it seems that Opa takes backward steps in managing (X)HTML
> elements as text strings with no object-oriented representation - which the
> DOM should provide on client
> and server-side. Is it possible to use DOM objects to completely model the
> view?
>

Once you have rendered your page (using xhtml fragments), you can access
them using the Dom module (i.e. the tree representation of your data is
available to you). You can
manipulate this Dom on both, the server and client side.

Alok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/opa/attachments/20130130/c0c67eda/attachment.html>


More information about the Opa mailing list