<div dir="ltr"><div>Matthias,</div><div><br></div>Hummm... I don't know about the tabs. Initially I was thinking it would be a good idea, then I tried to imagine how it would look like for linked layers within linked layers. We would have two choices:<div><ul><li>Have QTabWidget within QTabWidget: tabs within tabs is a UX nightmare<br></li><li>Switch to the current way of representing relations for sub-relations: that would lead to user confusion because we have two ways of representing relations.</li></ul><div>What do you think? To me, tabs is not a good idea.</div></div><div><br></div><div>Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 10:06 AM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Patrick,<br>
<br>
for the side that contains the foreign key, there is the "relation<br>
reference" widget which has a configuration option "show embedded form"<br>
(I haven't used it in years and a quick check on it didn't work, so<br>
maybe it needs fixing).<br>
<br>
Agreed, collapsed by default makes sense for huge models. For small ones<br>
it's a bit strange though. Another approach would be to put them on<br>
separate tabs by default, I think that could look quite nice also. What<br>
do you think?<br>
<br>
Regards<br>
Matthias<br>
<span class=""><br>
On 10/31/2016 09:54 AM, Patrick Valsecchi wrote:<br>
> Hi Matthias,<br>
><br>
> My screenshot shows only 1:N links. N:1 links are not supported. By N:1,<br>
> I mean the relations from the side that contains the foreign key. If I<br>
> open the form for the "appart" layer, it doesn't show the linked "maison".<br>
><br>
> Yes, the collapsed state is remembered, but the default should be<br>
> collapsed. If the default is to open everything, the GUI is going to<br>
> explode if we have hundreds of linked tables.<br>
><br>
> Thanks and CU.<br>
><br>
> On Sun, Oct 16, 2016 at 8:57 AM, Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a>>> wrote:<br>
><br>
> Hi Patrick,<br>
><br>
> Making forms and relations more usable is always welcome.<br>
><br>
> What exactly are the problems you have with the current solution?<br>
> I see that you mentioned the lack of the N:1 side which is available<br>
> including add feature, add link, remove feature, remove link pretty much<br>
> the way you describe it. On [1] there is some explanation I wrote on the<br>
> first implementation.<br>
><br>
> I think you should have found that since it's shown on the screenshot<br>
> which is attached to your mail.<br>
><br>
> Also lazy loading (load when first visible) was introduced once for<br>
> performance reasons and the collapsed state of the group boxes<br>
> containing the QgsRelationEditor widget is remembered.<br>
><br>
> So I think that functionality-wise, most of it should be there already.<br>
> With a lot of air left for improvement on the usability side.<br>
><br>
> Cheers<br>
> Matthias<br>
><br>
> [1] <a href="http://blog.vitu.ch/10112013-1201/qgis-relations" rel="noreferrer" target="_blank">http://blog.vitu.ch/10112013-<wbr>1201/qgis-relations</a><br>
> <<a href="http://blog.vitu.ch/10112013-1201/qgis-relations" rel="noreferrer" target="_blank">http://blog.vitu.ch/10112013-<wbr>1201/qgis-relations</a>><br>
><br>
><br>
> On 10/07/2016 09:27 AM, Patrick Valsecchi wrote:<br>
> > Hi,<br>
> ><br>
> > I'm tasked with making QGIS a bit more usable with complex database<br>
> > schemas having a lot of relations (up to hundreds of linked tables). The<br>
> > INSPIRE people were a bit too inspired when creating their data schemas<br>
> > and now we have to try to make QGIS able to cope with that.<br>
> ><br>
> > My concerns with the current situation (as of QGIS master) are:<br>
> ><br>
> > * We can specify the relations between the layers at the project<br>
> level<br>
> > (it's now easier with the auto-discover feature for PostGIS and<br>
> > Spatialite). But those are only showing in the QgsAttributeForm for<br>
> > the 1-N side (the side that doesn't have the foreign key). Why not<br>
> > on the N-1 side?<br>
> > * For showing the N-1 side in the QgsAttributeForm, one can define a<br>
> > Join in the layer's properties, but I don't see the point of having<br>
> > to define it here as well when we have already the relations info at<br>
> > the project level. I see a use for special joins, but for relations,<br>
> > I don't see why we have to define it twice. And the way it's<br>
> > displayed is not allowing to create joins or edit the joined fields.<br>
> > * I let you imagine the look of the feature attribute form when<br>
> there<br>
> > are hundreds of directly and indirectly linked tabled. This is just<br>
> > not usable if we display all of them directly like that. Just look<br>
> > at the attached screen shot that shows what happens by default with<br>
> > only 3 tables. It's already a mess.<br>
> ><br>
> > Now, what I propose is:<br>
> ><br>
> > * Not expand the relation widget (QgsCollapsibleGroupBox) by default<br>
> > and build it's content only when it is expanded the first time<br>
> > (think of what would happen when you have loops in the schema).<br>
> > * Show N-1 relations as well, in a collapsed by default<br>
> > QgsCollapsibleGroupBox, including a way to add a new linked entry,<br>
> > remove the link (put the FK to NULL) and delete it.<br>
> > * Add a button to open a related feature in a new window.<br>
> ><br>
> > What do you guys think?<br>
> ><br>
> > Thanks.<br>
> ><br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > Qgis-developer mailing list<br>
</div></div>> > <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a> <mailto:<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.<wbr>osgeo.org</a>><br>
<span class="">> > List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
> <<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a>><br>
> > Unsubscribe:<br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
> <<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a>><br>
> ><br>
> ______________________________<wbr>_________________<br>
> Qgis-developer mailing list<br>
</span>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a> <mailto:<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.<wbr>osgeo.org</a>><br>
<span class="">> List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
> <<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a>><br>
> Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
</span>> <<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a>><br>
><br>
><br>
</blockquote></div><br></div>