I'm generating networks and importing them into Cytoscape using cyREST.
I have a lot of extra information available about each node, more than can be fit into node labels. I would like the user to be able to click on a node and bring up a detail panel with this additional info. Is there any feature of Cytoscape, or an existing plugin that can do that?
There is no easy way from within CyREST to do that, although you could encode that information in a single text column and then use the 'tooltip' visual property to provide a way for a user to get the information on a mouseover. Beyond that, you would need to provide an app to integrate with your CyREST application. Several apps do exactly what you are describing (e.g. look at StringApp for an example)
-- scooter
This question may seems odd but we have a slight mixup within our Report Suites on Omniture (SiteCatalyst). Multiple Report Suites are generating analytics and it's hard for us to find which site URL is constituting the results.
Hence my question is, is there any way we can find which Site is filling data within a certain Report Suite.
Through this following JS, I am able to find which "report suite" is being used by a certain site though:-
javascript:void(window.open("","dp_debugger","width=600,height=600,location=0,menubar=0,status=1,toolbar=0,resizable=1,scrollbars=1").document.write("<script language=\"JavaScript\" id=dbg src=\"https://www.adobetag.com/d1/digitalpulsedebugger/live/DPD.js\"></"+"script>"));
But I am hoping to find the other way around that where Report Suite gets its data from within the SiteCatalyst admin.
Any assistance?
Thanks
Adobe Analytics (formerly SiteCatalyst) does not have anything native or built in to globally look at all data coming to see which page/site is sending data to which report suite. However, you can contact Adobe ClientCare and request raw hit logs for a date range, and you can parse those logs yourself, if you really want.
Alternatively, if you have Data Warehouse access, you can export urls and domains from there for a given date range. You can only select one report suite at a time but that's also better than nothing, if you really need the historical data now.
Another alternative is if your sites are NOT currently setting s.pageName, then you may be in some measure of luck for your historical data. The pages report is popped from s.pageName value. If you do not set that variable, it will default to the URL of the web page that made the request. So, at a minimum you will be able to see your URLs in that report right now, so that should help you out. And if you define "site" as equivalent of "domain" (location.hostname) you can also setup a classification level for pages for domain and then use the Classification Rule Builder and a regular expression to pop the classification with the domain, which will give you some aggregated numbers.
Some suggestions moving forward...
I good strategy moving forward is to have all of your sites report to a global report suite. Then, you can have each site also send data to a site level report suite (warning: make sure you have enough server calls in your contract to cover this, since AA does not have unlimited server calls). Alternatively, you can stick with one global report suite and setup segments for each site. Another alternative is to create a rollup report suite to have all data from your other report suites to also go to. Rollup report suites do not have as many features as standard report suites, but for basic things such as pages, page views, it works.
The overall point though is that one way or the other, you should have all of your data go into one report suite as the first step.
Then, you should also assign a few custom variables to be output on the pages of all your sites. These are the 4 main things I always try to include in an implementation to make it easier to find out which sites/pages are reporting to what.
A custom variable to identify the site. Some people use s.server for this. However, you may also want to pop a prop or eVar with the value as well, depending on how you'd like to be able to break data down. The big question here is: How do you define "site" ? I have seen it defined many different ways.
If you do NOT define "site" as domain (e.g. location.hostname) then I suggest you pop a prop and eVar with the domain, because AA does not have a native report for this. But if you do, then you can skip this, since it's same thing as point #1
A custom prop and eVar with the report suites(s). Unless you have a super old version of legacy code, just set it with s.sa(). This will ensure you get the final report suite(s), in case you happen to use a version that uses Dynamic Account variables (e.g. s.dynamicAccountList).
If you set s.pageName with a custom value, then I suggest you pop a prop and eVar with the URL. Tip: to save on request url length to AA, you can use dynamic variable syntax to copy the g parameter already in a given AA request. For example (assuming you don't have code that changes the dynamic variable prefix): s.prop1='D=g'; Or, you can pop this with a processing rule if you have the access.
you can normally find this sort of information in the Site Content-> Servers report. There will be information in there the indicates what sites are sending in the hits. Your milage may vary based on the actual tagging implementation, it is not common for anyone to explicitly set the server, so the implicit value is the domain the hit is coming in from.
Thanks C.
Literally I think the part will let me customize the property name of a specific content type in orchard. But when I attach this part to a newly created content type from the admin UI. All I got is 3 text fields with property names called "Custom One, Custom Two, Custom Three".
I couldn't find any examples from the web or from Orchard Source code explaining how should I work with it...
This part is obsolete. It used to be necessary for the List feature (also obsolete) to be able to sort on custom data. You should not be using that part.
I'm in the early stages of trying to learn Orchard, and I'm still seem to be struggling with the basics on how to build a page containing a multitude of various content that can be easily managed by non-technical users.
Ideally, what I'm trying to do is the following, I just can't figure out how to fit it into the Orchard architecture using Content Types, Parts, Fields, Widgets, Zones, etc. Also, since I'm still learning, I'm also trying to avoid any custom modules, or hard-coding content into the site (though I'm open to the idea, if that's the best way to get it done!).
Goal: Create a "home page" layout containing a Menu, Image slideshow, and several feature descriptions. For each image in the slideshow, I need a title, sub-title, description, and an image. To make this easy for non-technical users to manage, I would like to define the HTML template (custom Content Type, Part, or whatever), and allow authors to specify just those well-defined properties. I tried using Content Parts for this, but unfortunately, I can only have one Content Part of a particular type on a piece of Content. I also saw recommendations to create multiple Content Parts with the same set of properties, but I don't know how many images will be displayed (and I don't want to assign an arbitrary number).
I need to do something similar for feature descriptions, allowing authors to specify an image, title, description, and a page to link to. I'm running into the same problem as above, I'm not sure how to allow authors to specify a finite list of content, but have each content item be well-defined.
So far, the best option appears to be creating some sort of custom widget to "host" the content, but for some reason, my gut tells me that creating a custom layer for a single page just to specify which content to display is abusing the purpose of layers, which is begin able to customize a particular layout based on some criteria (whether or not the user is authenticated, for example).
I hope that made sense, and I apologize that it took so many words to explain my issue, I've just really reached my peak of frustration, and although I think that the Orchard guys definitely have it figured out in terms of architecture, I just can't get past these seemingly simple problems to build a simple website.
I greatly appreciate any tips, suggestions, advice this community has to offer!
TIA, -Jeremy
What you defined in Orchard terms is a Content Type named Feature.
Go to Contents -> Content Type, and click Create.
Select those parts by default:
Title, because you want your authors to provide a nice title/name for the features
Autoroute, which will create a SEO friendly url based on the Title (can be customized)
Click Save
Add specific Fields
SubTitle, of type TextField. Configure it to Default, Required.
Description, of type TextField. Configure it to TextArea, Required.
Image, of type Media Picker. Configure it to Required.
You can add some Hints to each fields, which will be displayed in the Feature editor to describe what to enter in each field. Very useful for authors.
Now you can create Features by clicking on the link in the top left part of the Dashboard.
Next step is to put those features on the homepage. What I suggest is to create a Projection which will be set as the homepage. A Projection is just a Page with an Url, which will display the result of a query as its content. The Query in your case will be "Give me all Features ordered by Creation Date".
In the dashboard, click on Queries
Click on "Create a new Query"
Enter "All Features"
Click on "Add a new Filter"
Select Content Type, then select Feature, Save
Click on "Add a sort Criterium"
Select "Creation Date", then Descending, Save
At this point, you can already preview the result of the query by clicking on Preview. But what we want is a front-end page.
Create a new Projection by clicking on Projection in the "New" section of the dashboard (top left again)
- Give it a title, and don't forget to check "Set as Home page" to make it the home page
- Select the only available query, named "All Featrues"
- Save
On the home page you should see all the features, ordered by date. But what you want is a slider. At that point you need two more steps:
- Integrate a slider jQuery plugin
- Render the HTML compatible with your jQuery plugin
By default, when you render a Projection it will use the standard "Summary" layout. But using projections you can decide exactly what layout you want to apply, and exactly what html tags and classes.
Edit the query named "All Features"
Add a new Layout
Select Html List
Select "Properties" and Save
Click Add Properties
Select Display Text, Save
Do the same for
Feature:SubTitle
Feature:Description
Feature:Image
Save your query
Edit the home page projection and select this specific Layout instead of the default one.
You will see that each property is rendered in an html container.
By editing each property you can decide which class to apply, and which html tag to use. By changing them you can render exactly what you want, and customize your CSS/HTML to render the slider nicely. This is purely your HTML know have to apply here, or find some articles about that.
For your editors, they just have to go to the dashboard and add/update some feature content items, it will be reflected on the website.
Optionally there is a Slider module on the Orchard Gallery. You can try this one too. But if you want to handle exactly what happens the technique I described is better.
I've just gone through this exact scenario myself. I think that what you want can be accomplished using Orchard Lists. The UX is not exactly intuitive for the end user, but it seems like it's the most straightforward way to accomplish this goal without installing/developing a custom module.
First, make sure you're using Orchard 1.4 because you'll need the built-in support for generating alternates for Container Widgets for each zone. Enable the Shape tracing, Url alternates and Widget alternates modules.
Now, create a list of items as described in the documentation (see http://docs.orchardproject.net/Documentation/Creating-lists). Translate "book review" into "slide" and "book reviews" into "slides" and you get the idea. You can add custom fields to represent your subtitle, description, etc. I'd just keep the image as part of the content itself instead of creating a custom field for it.
If you've followed the steps in the documentation, you should now be seeing a list of your slides rendered as ul/li's. Now you'll want to customize how things are rendered so you can show your custom fields and generally customize the tags. Use the shape tracer and create alternates for the list as you see fit. Now you're free to control all the rendering. See http://weblogs.asp.net/bleroy/archive/2011/03/27/taking-over-list-rendering-in-orchard.aspx and http://weblogs.asp.net/bleroy/archive/2011/05/23/orchard-list-customization-first-item-template.aspx for ideas.
Managing this list from your end-user's perspective is actually quite easy, but I don't really feel that it's very intuitive.
It took me three days of digging through blogs and docs to figure this out for myself.
I'd also recommend this wonderful module called Featured Item Slider. It has all the basic functionalities of a slideshow, including all mentioned in the question, plus some fantastic additional capabilities, such as different animations. You can also fine tune the layout and styling by providing additional css. Get the source here. And here is the slideshow in action. If a module already exists providing the functionality you're looking for, then it's best to use that rather than reinvent the wheel, unless you do it for learning purposes.
i've used contentproviders with DB.it has some data in it.i need to make those data available to all other applications.How? Usually the main use of content provider is to store and retrieve data and make it accessible to all applications. They’re the only way to share data across applications; there’s no common storage area that all Android packages can access.I used the code from below link..
http://ashwinrayaprolu.wordpress.com/2011/03/16/custom-content-provider-in-android/
Distribute your Content URI and define your API.
Provide the string of your Content Authority and the paths you recognize. Explain to your users how the tables in your DB map to your paths. Document what the columns in your tables are. Users with your content URI can read and write your databases using standard calls to ContentResolver and the insert/delete/update/query calls.
Provide access control in your <provider> tag in your AndroidManifest.xml. Look at The documentation especially with regard to android:exported, android:grantUriPermissions, android:permission, android:readPermission and android:writePermission. You'll need to decide how to use those based on your use cases. Also, the <grant-uri-permission> tag will give you even more fine-grained control.
Write other apps to use those calls you just documented and allowed permissions for.