10:59 a.m.
So, an update:
I implemented support of json and yaml schemas to generate views
dynamically. A schema looks like this:
{
"summary": [
{"name": "id"},
{"name": "active", "alias":
"is_active"},
{"name": "full_name", "alias":
"name"}
],
"foo": {"name": "foo"}
}
Which is functionally equivalent (it actually generates a view dynamically
with the same ruby code) to this:
pane :summary do
field :id
field :active, :is_active
field :full_name, :mario
end
field :foo
And this is how it could be used to generate the views from data:
render json: View.from_json(unparsed_json).new(entity)
render json: View.from_yaml(unparsed_yaml).new(entity)
render json: View.from_hash(data_as_hash).new(entity)
Since those methods generate classes, they can be used to inherit new
views, or even doing something like this:
class EAPServerView < View.from_json(:code_to_get_from_hawkular)
end
Also, another important thing is that methods defined inside a view are
used for the rendering, so attribute transformation can done in the view,
instead of the entity if necessary, like this:
entity = OpenStruct.new(foo: :bar)
class MyView < View
field :foo
def foo
:baz
end
end
Then rendering it would return something like { "foo": "baz" }.
The changes are available on the same repo as always:
github.com/cfcosta/dynamic-entity-poc , and you can find examples on how
this work on view_spec.rb, and examples of schemas on
spec/fixtures/view_import.*
On Tue, Jul 18, 2017 at 9:42 AM, Heiko Rupp <hrupp(a)redhat.com> wrote:
On 17 Jul 2017, at 15:59, Caina Costa wrote:
> If we have a WildflyDomainControllerServer to render, first it will
> try to find WildFlyDomainControllerServerView, then
I (still) consider that a problem, even if better than what we have now.
I can't tell e.g. the Infinispan folks "Listen you know your stuff
better than we do, so please start writing Ruby code and create a
pull-request against the hawkular-provider gem"
My goal really is to externalise that as much as possible (in to the
hawkular-server or agent side), so that it is
possible for other groups to write the description in e.g. JSON for
their UI and the relation between Entities.
Having that in Hawkular/Agent also allows us to introduce new supported
stuff outside the release cycles of ManageIQ and their downstream
CloudForms.
I am not even sure if e.g. introducing support for Infinispan could be
part of a z-Stream release, which is supposed to be bugfixes only.
So if we'd miss CF 4.6 GA, we can only support Fuse in the CF release
after 4.6 GA, while if the UI is driven from (meta)-data on the Hawkular
side, we can update the Middleware Manager / agent and the support would
show automagically.
Of course we may at some point in time create more specific UIs for some
task, but the 80% case should work without modification of MiQ code.
We need to generate the views dynamically, by fetching the (meta) data
and the schema and generating the view from that. That means we don't
need to change anything on ui-classic to add new entity types.
Those *EntityView Ruby objects need to be created from data retrieved
from the Hawkular side and not by checking in new code into the
hawkular-provider gem when supporting new Entities.
The metadata should probably stored inside MiQ for faster access, but
that is a 2ndary concern.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev