well about those thing,
we need more detail explain about @felipealmeida , so I'll request his comment when he come to the office :)
but felipe was on the side of not using dynamic class...
okay I stop to update the patch for now...
and let's get clear conclusion regarding this matter.

In D7529#134334, @SanghyeonLee wrote:

can you check the efl_ui_property.eo?
about the factory,
we all know the purpose of factory bind, so it need to be called always these two API as the pair.
so why not making it one API?
porperty bind will be internally handled.

hmm... yeah I agreed with that. so I'll update the patch with making it inherit from layout.

In D7529#134335, @SanghyeonLee wrote:

we do this because,
factory.icon.bind_factory(imgf);
is unable with current list item factory design.

factory cannot distinguish Efl.Part depending on each item classes,
so we vote the way and we drop it as I remembered in the Efl.Part task.

In D7625#134336, @SanghyeonLee wrote:

Actually I thought that we might need to remove layout factory cause I cannot find any case of using it till now, but still you think it is necessary, I can go with your idea.
but we have to think about maintaining one more class which may not often used.... if you can find any use case, it should be left.

Actually I thought that we might need to remove layout factory cause I cannot find any case of using it till now, but still you think it is necessary, I can go with your idea.
but we have to think about maintaining one more class which may not often used.... if you can find any use case, it should be left.

we do this because,
factory.icon.bind_factory(imgf);
is unable with current list item factory design.

can you check the efl_ui_property.eo?
about the factory,
we all know the purpose of factory bind, so it need to be called always these two API as the pair.
so why not making it one API?
porperty bind will be internally handled.

proposal interface eo.
the code is not working yet.
If property_bind_part is too ambigiuous, we can go with property_bind_text.

In D7529#134326, @SanghyeonLee wrote:

and.. about

efl_ui_bind_property(imgf, "", "path"); //connect to "path" property
efl_ui_bind_factory(factory, "efl.icon", imgf);

we could make it one line calls,
efl_ui_property_bind_factory(factory, "efl.icon", "path", imgf);
the goal is alway bind the property data with given subfactory and sawllow in the content, so I think make it one line is more natural I think.
any opinion?

and.. about

efl_ui_bind_property(imgf, "", "path"); //connect to "path" property
efl_ui_bind_factory(factory, "efl.icon", imgf);

@cedric I know its same but we can have this specific function for explicit declaring on Efl.Part controls. so this will let user/widget both understand what action will happen by API calls.
if you not a fan of this idea, okay, I can drop it.

rebase the patch with resolving merge conflict.
this patch need to be fixed yet.

In D7625#134318, @SanghyeonLee wrote:

@cedric that's true but I wonder we still need to maintain layout_factory or not. do we need it?

and also need to fix few thing in the view... it still using layout terms and class so it need to be changed Efl.Ui.Item as I see.. will be updated soon.

@cedric that's true but I wonder we still need to maintain layout_factory or not. do we need it?
and also some style set and size calculation will be different, so I don't know we can solve this with calling efl_super...
layout factory may need to be fixed too then.

rebasing patch

this never should have even passed review. it's obviously wrong - the code path is used. a simple look at the for loop being removed would have shown that

In D7529#134161, @SanghyeonLee wrote:

interface : Efl.Ui.Property
: property_bind; generic function for binding property with input key string.
: property_bind_part : binding property with given Efl.Part.
: property_bind_signal : binding property with given signal string, and emit the signal when model ready.
: property_bind_factory : binding property with given factory and create object by factory and swallow in gvien Efl.part.

go this way?