Jon (LabKey DevOps) responded: |
2015-10-21 12:36 |
Hi Leo,
I added the bodyClass to an existing QWP I made like this:
var qwpDataset = new LABKEY.QueryWebPart({
bodyClass: 'dataset-body',
queryName: <some query>,
schemaName: <some schema>,
renderTo: <dome div id or el>
});
qwpDataset.render( <dome div id or el> );
Then I ran the following in the Google Developer Console:
$$(".dataset-body")
And got actual results (see screenshot).
Can you re-try it with the double $$ and double quotes?
Regards,
Jon |
|
|
Leo Dashevskiy responded: |
2015-10-21 14:14 |
I tried with double quotes and double dollar sign and still an empty array.
Here is the equivalent part to what you showed in my own DOM:
<div id="ext-comp-1080" style="height: auto;" class="">
<div>
<form method="post" id="aqwp339" action="">...</form>
<script type="text/javascript">...</script>
</div>
</div>
Jon, the difference that I see is that you have both the "renderTo" config and the .render() call.
Can you try and see what you get with the way I have it, which is without the 'renderTo' config?
Moreover, I think you're rendering directly into the main web part's body, whereas my call is like this:
qwpDataset.render( cntDataset.getEl() );
where "cntDataset" is an Ext Container:
var cntDataset = new Ext.Container({
defaults: {
border: false
},
items: [],
layout: 'fit'
});
which sits within another Ext Panel:
var pnlData = new Ext.Panel({
autoScroll: true,
bodyStyle: 'padding: 1px;',
defaults: {
autoHeight: true,
border: false,
hideMode: 'offsets'
},
items: [ cntDataset ],
tabTip: 'Data',
title: 'Data'
});
and pnlData in turn sits within a TabPanel:
var pnlTabs = new Ext.TabPanel({
activeTab: 0,
autoHeight: true,
defaults: {
autoHeight: true,
bodyStyle: 'padding: 4px;',
border: false,
forceLayout: true,
hideMode: 'offsets',
style: 'padding-bottom: 4px; padding-right: 4px; padding-left: 4px;'
},
deferredRender: false,
forceLayout: true,
items: [
pnlData
],
layoutOnTabChange: true,
minTabWidth: 100,
resizeTabs: true
});
and finally that top panel sits within the parent-most panel, which renders into the web part's body:
Ext.namespace('LABKEY.ext');
LABKEY.ext.DataExplorer = Ext.extend( Ext.Panel, {
constructor : function(config) {
// ALL THE CHILDREN CONTAINERS AND LOGIC FROM ABOVE
this.border = false;
this.boxMinWidth = 370;
this.cls = 'ISCore';
this.frame = false;
this.items = pnlTabs;
this.layout = 'fit';
this.renderTo = config.webPartDivId;
LABKEY.ext.DataExplorer.superclass.constructor.apply(this, arguments);
}
}); |
|
Leo Dashevskiy responded: |
2015-10-21 14:18 |
To be fair the docs do say:
"A CSS style class that will be added to the enclosing element for the web part."
but since the target of rendering the QueryWebPart is not limited strictly to just the web part itself, I was expecting whatever the target is for it to receive that "bodyClass" config.
Does that not make sense?
That way one can manipulate that particular instance via CSS - that's one benefit of this I'm seeing and I'm after.
Shouldn't be a terribly difficult fix, right?
Thanks.
-Leo |
|
Jon (LabKey DevOps) responded: |
2015-10-21 17:35 |
Hi Leo,
I removed the renderTo: option and doing $$(".dataset-body") still worked for me.
It was only when I did $$(".dataset-body") did I get just an empty array like [].
Doing $(".dataset-body") throws up a TypeError on my end stating:
Uncaught TypeError: $ is not a function (...)
Is it possible to send me your full code without the comments that you're inserting into a wiki page? Trying to cobble your code together into what I have is throwing up a configuration error tied to the render() method.
Regards,
Jon |
|
Leo Dashevskiy responded: |
2015-10-21 18:06 |
Jon,
I don't see the difference between your $$(".dataset-body") calls in 2nd and 3rd lines in the post above...
Ok, I think, I got to the bottom of it, sort of.
I initially included a stripped-down example for the sake of simplicity, but in fact I apparently omitted a part, which makes our 2 instances behave differently!
Go ahead and add
frame: 'none',
to your QueryWebPart config
Then query for the 'dataset-body' class once again - do you see it?
I say in this case, still, whatever it is that the QueryWebPart ended up being rendered into, it should still have the added class value specified in bodyClass.
-Leo |
|
Jon (LabKey DevOps) responded: |
2015-10-22 11:01 |
Hi Leo,
I confirmed what you stated, it does appear that when you add "frame: 'none'" to the QWP, the array is definitely empty.
I'll have to check on my end to see why this is the case, but I'm certain this might be a bug.
Regards,
Jon |
|
Leo Dashevskiy responded: |
2015-10-27 12:54 |
Jon, if there is already a bug report open in your own system regarding this, do you mind referencing it here and also adding me to the notification list, when the status changes?
Thanks. |
|
Jon (LabKey DevOps) responded: |
2015-10-27 15:34 |
Hi Leo,
So far in investigating the behavior, this isn't quite a bug, but an old design that goes pretty far back in the code's history.
There is potential that if we do attempt to change the behavior, it may cause other parts of the UI to fail.
Can you provide me with an explanation on why this functionality is needed? By having a better understanding of the business need/impact, this will help prioritize the request to have the behavior to be changed.
Regards,
Jon |
|
Leo Dashevskiy responded: |
2015-10-28 10:06 |
Well, just being able to customize a particular instance via CSS and manipulate it via jQuery - I guess, that's the main benefit for me with this. |
|
Jon (LabKey DevOps) responded: |
2015-10-28 15:49 |
|
|
Leo Dashevskiy responded: |
2015-10-29 10:44 |
Thanks, Jon.
I cannot see how keeping the current behavior for webParts that have frames intact and creating the expected behavior for a webPart (just adding an extra custom class to its wrapper/parent), which has its frame config set to 'none', can cause other parts of the UI to fail. Unless, of course, the custom class is something wack, then the UI can fall apart, but that's up to the dev to specify the correct extra class... |
|
Jon (LabKey DevOps) responded: |
2015-10-29 11:20 |
Hi Leo,
I'm not sure how deep this goes, but a cursory glance at the code showed this is pretty old and a lot of components are now sitting on top of it. But you might be right and this may have no impact to the rest of the platform if modified.
We'll keep you informed to the status of this bug as we get more details.
Regards,
Jon |
|
Jon (LabKey DevOps) responded: |
2016-12-27 19:37 |
Hi Leo,
We've revised our documentation in 17.1 on the bodyClass via revision number r47410.
"Note, this may not be applied when used in conjunction with some "frame" types (e.g. 'none')."
Regards,
Jon |
|
Leo Dashevskiy responded: |
2017-01-13 17:54 |
What? Instead of fixing it, you guys just tweaked the docs... first time I'm encountering such a sneaky approach from LabKey :) Oh well ... |
|
Matthew Bellew responded: |
2017-01-14 09:26 |
Note that frame:'div' is the simplest frame that supports bodyClass. |
|