Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Web parts accessing other web parts?

  Asked By: Arnold    Date: Apr 30    Category: Sharepoint    Views: 3297

Web App A - Serving generic user requests and housing
all publicly available web parts. This web app would
run using minimal trust levels.

Web App B - Used for specific web parts which runs at
a full trust level. These web parts would be used for
a variety of different purposes.

Would it be possible for web parts in Web App A to
reference data from Web parts in Web App B while
maintaining the minimal trust level already
configured? My idea would be to be able to have an
area for "widgets" without compromising the security
of our general purpose user application. Does this
work or would I have to set full trust levels on Web
App A to access Web App B?



11 Answers Found

Answer #1    Answered By: Peter Peterson     Answered On: Apr 30

If you are planning to use Webpart connections to transfer the data  between the
webparts it won’t work. You can use SPD to connect webparts that aren’t
located on the same page, but you can only connect with webparts that are
located on a page in the same site. If you use the object model you would need
the same trust  level on web  App A as on App B. Remember that webparts don’t
actually store data, they are a User Interface into another datasource.

Answer #2    Answered By: Kalyan Pujari     Answered On: Apr 30

Well, I thought that's what CQWP's did. Don't they do
lookups on the data  contained in other web  parts such
as custom lists?

Answer #3    Answered By: Isidro Berger     Answered On: Apr 30

Actually, CQWP's do lookups against lists and libraries not webparts. I find
that a lot of people confuse a list and the ListView webpart that displays the
list. The webpart only displays the data, you have to go to the list to get the
data unless a web  part connection is available.

I think CQWP uses XML webservices to actually access  the data. Also, the CQWP
is located in the GAC and runs with Full Trust no matter what Trust Level the
Web App is running at.

Answer #4    Answered By: Schuyler Le     Answered On: Apr 30

OK, I guess it's a matter of semantics then. I
consider lists and libraries to be web  parts as well.
It sounds like the CQWP will work for me. Do you know
if the CQWP can perform compares against more than one
data source? I'd like to use a BDC display as one
sort and then a custom list as the seperate sort and
only match for duplicates.

Answer #5    Answered By: Kristina Cox     Answered On: Apr 30

> OK, I guess it's a matter of semantics then. I
> consider lists and libraries to be web  parts as well.

Perhaps you also consider a web page as a database, because it displays
information from a database. When you go to manage the web page, however,
you will find that database tools don't work.

Yes, it's a question of "semantics" -- the study of meaning in language.
Your approach simply obfuscates the meaning of the practical language we

Answer #6    Answered By: Delbert Frederick     Answered On: Apr 30

And this provides value how? I was merely responding to the
statement that web  parts cannot contain data. Document Libraries
and Custom lists are web parts  and they contain data. What's the

Answer #7    Answered By: Willard Valenzuela     Answered On: Apr 30

They aren't web  parts. They are presentable in web parts, but they
aren't web parts; they're lists. That's the issue - your semantics
are incorrect.

Answer #8    Answered By: Allison Stewart     Answered On: Apr 30

I apologize for the confusion then. I've always been told that while acting
under different rules, that document libraries and lists were still web  parts.
I'm guessing that the thread dying is probably because everyone realized I had
no idea  what I'm talking about.

Joshua, if my comment seemed snide then I apologize for that as well, as that
was not my intention.

Answer #9    Answered By: Emmett Hyde     Answered On: Apr 30

Just to try to clarify this common misconception. Every visible
instance of a library or list is indeed a listview webpart. These are
used on the main page of the site and the edit, create, and list pages
that allow you to add/modify/list data  to the list or library. But the
data is stored elsewhere. The listview webpart provides a way to see
into the datastore. Unless a webpart is designed to pass data on
through a connection they are only a means of displaying data. This
becomes a critical distinction when we use the Content Query web  Part to
aggregate data from a variety of lists. Although you can aggregate the
data you can only display it using the CQWP's capabilities. You can't
use the CQWP as a datasource in and of itself. That's why you can
create an aggregated Events list using the CQWP but can't display it as
an actual Calendar. The CQWP doesn't have that capability and you can't
have it aggregate the data and then pass it to a dataform webpart
because its just a webpart not a data source.

Answer #10    Answered By: Michelle White     Answered On: Apr 30

Once again, you have provided a clear and deep, yet
concise, explanation.

Answer #11    Answered By: Sheena Ray     Answered On: Apr 30

Mark, I very much appreciate your apology. I realized after sending that my
remark had an argumentative tone. I apologize for that. This group is so
helpful, and its friendliness is part of its helpfulness. I'm glad we've
recovered from that momentary slide.

Didn't find what you were looking for? Find more on Web parts accessing other web parts? Or get search suggestion and latest updates.