[Development] Can we have id's in dynamically generated elements for the next QML?

[Charley Bay]

 Mark spaketh:

> Sadly, QML 1 doesn't have id in dynamically generated id. That is a
> real big pain if you want to drag/drop something since then you
> need... an id! Right now i'm trying to fight against a lot of issues
> that wouldn't even be there if i simply had an ID. You can read more
> about that in this blog post:
>
> http://kdeblog.mageprojects.com/2012/08/01/what-will-qml-calendar-have-progress-update-qml-issue/
>
> I'm also curious to know why the decision was ever made to have
> dynamically generated elements exist without id?
>
> Is there any possibility that QML 2 (or QML 2.1 or whatever comes
> after 2) is going to have ID's for generated elements?
>

This is an interesting thing that I'm still trying to "grok" (the
direction-forward is not obvious to me yet, and I'm not sure what the
Trolls have discussed on IRC).

I know it's been discussed (a little), and that I'm not sure I'm about to
add much.

IMHO the issue is this "declarative-approach", which IMHO is quite new as a
paradigm.   The QML components/items themselves are "independent-actors".
 They don't use layouts *explicitly* in the parent/child relationship, and
shouldn't (but yes, "layouts" can be implemented to visually place
collections of items, and that is legitimate).  While "imperative"
organization is possible, it seems it should be discouraged as
"not-best-practice".

I'm not-yet sure whether IDs are part of that topic:

*- I *know* instance-IDs are needed for imperative.

*- I *don't* know if instance-IDs are needed for declarative.

(This is my internal speculation/mapping, I'm just trying to
understand/grok the new paradigm to where "best-practices" become obvious
to me.)

For example, in the design/problem you describe, the following design
option *might* be reasonable without IDs (and I concede many other design
options exist if we *do* have IDs):

*- The "MyCalendarEntry" (QML component, no GUI real estate) has a
"DateTimeSpan" property which "implies" where it is on a calendar.

*- A "MyCalendarItem" (QML item, with GUI real estate) "parents" (or
"references") a SINGLE "MyCalendarEntry" to represent that
"MyCalendarEntry".  (Conceivably it would be 1:1, but it seems reasonable
to have many "MyCalendarItem" GUI-things represent the same
"MyCalendarEntry" instance if there were many "views" of that one "entry"
in different calendar-rendering-scenarios.)

*- Each "MyCalendarItem" (QML GUI item) is an "independant-actor" which
"finds-its-place" upon a parent "MyCalendarDisplay" QML GUI item.  The
parent "MyCalendarDisplay" has its own "layout" that physically arranges
its "children", which occupy their own real-estate-needs (based on their
internal "MyDateTimeSpan" property).  (For example, perhaps the
"calendar-display" is a "MyCalendarDay" or "MyCalendarWeek" or
"MyCalendarMonth" GUI-item, and there would be different layouts for each
of those instances.)

*- This works "without-instance-IDs" because creating a "MyCalendarEntry"
would *automatically* trigger creation of a "MyCalendarItem", which is
*automatically* parented by a "MyCalendarDisplay", and which physically
places the items with Z-order.  The drag/drop manipulation would directly
manipulate the "DateTimeSpan" in the "MyCalendarEntry", through the
"handles" on the "MyCalendarItem".

Of course, another design option would be for the "MyCalendarEntry" QML
component to have a C++ back-end-object with a unique ID, which could be
used for a universal ID from within QML.

I dunno.  I'm about to embark on a fairly large Qt5/QML effort and that's
the kind of design I'm looking at, and I'll know more when I get deeper.
 At the moment, though, I concede it would not take much for me to agree
with you that IDs could/should be added to the next QML spec...

Specifically for your question:

I'm also curious to know why the decision was ever made to have
> dynamically generated elements exist without id?


I'm not an authority, and can only speculate, but I was initially confused
about this too.  (NOTE to the casual reader, the "Item { id: my_id; }" is
not the ID we're discussing, we're talking about an instance-unique ID.)

However, after a time, I came to understand that the "declarative" approach
seems to imply:

(a) Items are "implicitly-aggregated" based on "parents" and "properties"
(e.g., typically not explicitly-aggregated)

(b) Declaratively changing an item's "parent" and/or "properties" (such as
"events-on-implied-items") should *implicitly* cause animations and
re-aggregations (such as implied re-parenting and re-layout on the
display), and you're not supposed to need to do the
explicit-place-this-item-here thing.

As a possible secondary issue, if the QML item "represents/wraps" a C++
object, then the "ID" is trivially handled with an application-specific
"identifier" (that's typically how mine work, where the "identifier" has
compound-application-specific-state).

The question in my mind, of course, is the same as yours:

(1) If "ID" is not really needed, what is the "best-practices"
declarative-QML-design-pattern that would do what we need?  (One possible
pattern-not-yet-proven is listed above.)

(2) Are the designs not reliant upon (instance)-IDs reasonably practical
for non-trivial systems (e.g., systems that make heavy use of a
"model-of-items")?

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120801/46b345c1/attachment.html>