(Migrated) Using Django templates to generate HTML with Zato services

(This message has been automatically imported from the retired mailing list)

Hello,

I’ve just published an article on the blog on how to produce HTML output
with Zato services.

https://zato.io/blog/posts/using-django-templates-to-generate-html-with-zato-services.html

This was asked about before so here it is :slight_smile:

I’m exciting for the new zato features, like restful channels, when is
scheduled the next release for this features? is there any developer docs
for developing zato componentes and features?? I need to get deep in zato
to get a good understanding and to develop some features like complex SIO
data types, service validation requirements or use restful channels.
I will use zato as a key component of my architecture, and I will share
everything for the community
cheers

On Sun, Oct 27, 2013 at 12:58 PM, Dariusz Suchojad dsuch@zato.io wrote:

Hello,

I’ve just published an article on the blog on how to produce HTML output
with Zato services.

https://zato.io/blog/posts/using-django-templates-to-generate-html-with-zato-services.html

This was asked about before so here it is :slight_smile:

On 10/30/2013 06:10 AM, Axel Mendoza Pupo wrote:

Hi Axel,

many thanks for your enthusiasm! :slight_smile:

I’m exciting for the new zato features, like restful channels, when is
scheduled the next release for this features?

My current workflow is that I develop features in feature branches and
once they’re ready they’re merged into the master branch.

So far the only exception to that rule was guaranteed delivery - this
feature is not complete in every aspect but I needed it in one place and
had to merge it into master anyway.

Apart from that, everything that is ready flows into master. So if
there’s something you’re interested in but can’t wait for the full
release, you can simply run from master.

As for the 1.2 release - I believe this should be around April-June 2014.

Here’s the list of open tickets for this release, though by no means
this is a complete one, more will be added still.

And here are the ones already done

That said, what will be done in this year will include (roughly in this
order):

  • RESTful channels and outconns - within 1 week I believe
  • SSL/TLS (but no client certificates validation this year)
  • Integration with NewRelic
  • SIO headers (more on that below)
  • Unification of JSON, XML, CSV, GET, POST and RESTful params for SIO
    (also below)

Basically, what gets in is a result of my following the vision of how
Zato should look like with input from users who have their own needs and
excellent ideas.

is there any developer docs
for developing zato componentes and features??

Not yet, nope. There was no real need for it yet - best thing is to get
yourself familiar with the architecture, that is, start with this
document …

https://zato.io/docs/architecture/overview.html

… and read all the links.

Next one is checking out the public API …

https://zato.io/docs/public-api/intro.html

… as this presents a concise lower-level developer view into what Zato
can offer.

Armed with that knowledge you just need to peek into the source code and
use this list to discuss anything you need. I’m sure we’ll work out a
good approach to the development.

I need to get deep in zato
to get a good understanding and to develop some features like complex SIO
data types,

Something what I’ll be working on in upcoming weeks is unifying JSON,
XML, CSV, GET, POST and RESTful params for SIO, so that regardless of
what you send you’ll get a coherent set of SIO parameters in
self.request, for instance with this RESTful URL template …

POST /customer/{cust_id}/order/{order_id}

… sending

POST /customer/11/order/22?branch=33

{
“quantity”: 44,
“price”: 55,
“currency”: “EUR”,
}

Will give you SIO parameters

self.request.cust_id # 11
self.request.order_id # 22
self.request.branch # 33
self.request.quantity # 44
self.request.price # 55
self.request.currency # ‘EUR’

Naturally as always with SIO - no programming will be needed, this will
be automatically populated.

There are caveats to take care - such as keeping a config of what has
priority over what (i.e. what if you send cust_id in more than 1 place)
but this is the idea.

Another SIO-related work will be headers.

Right now you can either return an object or a list of objects. So
either a single order or a list of orders. But with headers it will be
possible to return, say, customer details and a list of orders for that
customer.

This would look like …

class SimpleIO:
output_header_required = (‘cust_id’, ‘cust_name’)
output_optional = (‘order_id’, ‘product’, ‘quantity’)

… and would output correct JSON or XML

{
“cust_id”:11,
“cust_name”: “Cust Name”,
[
{“order_id”:1, “product”:“foo”, “quantity”:50},
{“order_id”:2, “product”:“bar”, “quantity”:200},
]
}

(I’ll skip XML)

And that I think is where I’d like to stop with SIO though maybe there
should be more added? I’m not sure yet.

On the other hand, I know there are already packages like micromodels

that perhaps could be used instead of SIO for more complex structures?
Perhaps instead of developing everything into SIO we should make
micromodels, or something similar, an alternative?

What do you think? What your idea is?

service validation requirements

Can you please tell me what you’re thinking of here? My idea so far was
to be able to turn SIO definitions into XSD and further - into WSDLs.

This should be easy to do, simply scan all the required and optional
fields and generate appropriate XSD elements that will be wrapped into a
common WSDL document.

Or RelaxNG, we could generate that one with time, too.

A similar approach can be used for JSON validation though I’m not sure
what we’d be using for that one as there doesn’t seem to be a clear
preference among people on what to validate JSON with.

or use restful channels.

This will simply work, i.e. no knowledge of internals will be needed,
you’ll just specify a URL as

/order/{oid}/date/{date}

and you’ll have …

self.request.oid
self.request.date

… in your service. This won’t even required you to use SIO.

I will use zato as a key component of my architecture, and I will share
everything for the community

This is great and I’m sure we can think of many interesting ways to make
everything as pleasant for you as possible :slight_smile:

Please, if you’d like to discuss any ideas, needs or stuff you’d find
useful, let’s talk about it here so others can chime in too.

cheers and take care,