[Opa] best practice coder and designer working together?

[Owen Gunden]

On Sat, May 5, 2012 at 9:56 AM, cs joe <chinasmilejoe at gmail.com> wrote:
> After first reading on doc, just got one concern for how coder and designer
> working together?
> Any one could share practical tips? especially how opa may help designer do
> their job quickly and efficiently.

Hi Joe,

Opa is flexible, so if you like, you can pretty much do the same thing
as you did with whatever language you used before. You can do
model-view-controller and have the designer work on the views, or you
can structure things differently, however works for you.

One difference is that your designer should know at least a little
rudimentary Opa, to get the syntax of functions and a few other simple
constructs. It's kind of like learning a templating language, except
it's more useful/powerful because it is the same language used for
coding in other parts of the project.

For example, you might place the UI and backend parts of the
application into separate files. One way to structure this is to have
each "view" or "page" be rendered by a separate function, in a
separate file. Then you can have the main routing code call out to
that page.

pages/index.opa:

module Index{
  function page() {
    <div>some html</div>
  }
}

main.opa:

function dispatch(url) {
  match (url) {
    case {path:[] ... } :
      make_page(Index.page());
    // and so on
  }

(where make_page is a function that takes xhtml and creates a Resource
out of it using e.g. Resource.styled_page or similar)


For css, you probably want to just include an external css file.

Then you can share the code between you with a git/hg repository, and
you shouldn't be working too much on the same files.

Finally, I will say that from the designer's point of view (and the
programmer for that matter), the amount of time it takes for a
complete cycle of change, compile, run, test can be painful,
especially after the app gets bigger. There are two things I do to
mitigate this pain:

1. Launch the app with --debug-editable-all (or -d). That means you
can edit certain files (e.g. css, images) at runtime to explore what
might happen if you changed this or that. However, a few times I've
run into problems where the running app doesn't pick up my change.

2. Use chrome, and use inspect element. From the inspector, you can
change markup and css on the fly and see in real-time how your changes
will be rendered. This is what I do most of the time when I'm working
out design issues, and it works beautifully.

Good luck,
Owen