Project information
New Project Page: http://drupal.org/project/embed_widgets
Demo/Test Site: http://www.deviable.com/widgets
Description
Provide an Embeddable Widget option for Drupal pages. This will enable the page to be embedded to any website as an IFrame or Google Gadget. The API will be designed in such away that will allow it to support many more types of widgets such as JavaScript and Flash.
Original discussion of the project: http://groups.drupal.org/node/9633
Deliverables:
- A module that provides an API to allow the creation of embeddable widgets.
- A module that provides a user interface to the API.
- A module that provides embeddable widgets using IFrames.
- A module that provides embeddable widgets using a third party platform such as Google Gadgets/OpenSocial (XML).
- Documentation for each of these modules.
Dependencies:
Specifications
- Widgets API Module
- Provides functions for loading, saving, and deleting widgets.
- Provides functions for theming widgets.
- Provides hook for modules to specifiy widgets.
- Provides hook for future modules to register additional widget types.
- Widgets consume data sources from URLs. This way it can connect to either Services or a Drupal path.
- Widgets UI Module
- Provides user interface to administer and customize widgets.
- IFrame Module
- Generates code to embed an IFrame widget.
- Google Gadgets/OpenSocial Module
- Generates code to embed a Google Gadget widget.
Resources
Drupal
Third Party Integration
Project schedule
Subject to change...
May 26-July 7:
Create the API and UI modules.
July 7-August 11:
Create IFrame and Google Gadgets module.
August 11-18:
Make sure documentation is complete. Thoroughly test features as specified in the Project Details.
Status updates
2008-08-12
My apologies for no update last week! This week's progress:
- Almost completely re-did the user interface. It's much better! Thank you, to those who reviewed my projects usability.
- Created Embed Widgets settings page(s) under Site Configuration.
- Along with new UI, users (non-admins) can now create and edit widgets if they've been given permission
- Created Facebook module. Widgets can now be embedded in Facebook applications.
- Better handling of widget sources created by modules via API: They can be enabled/disabled, similar to Views and Blocks.
- Added "Embed" button to embeddable content and to widgets. This button can be turned on/off on settings page.
- Made changes to JavaScript that now handles multiple widgets on same page, even if it is multiple instances of same widget or widgets from multiple domains.
Plan for coming week:
- Fix any bugs that I discover.
- Finish documentation: Handbook, help, README, project page.
- Simple Tests
Challenges:
Cramming in the features I want. :)
2008-07-29
This week's progress:
- Added widget customization features: Theme, width, and height can be set. Custom theme can be made.
- For custom theme, font size and background color can be set. Given the background color, an entire color scheme is generated using Color Scheme API.
- Created Color Scheme API module to make widget theme customization easier.
- For custom widget theme, CSS is generated dynamically.
- Added API functions to encode and decode/validate widget information for secure use in URLs.
- Began implementing hook_widgets() and new API functions to allow other modules to declare widgets and widget sources in code.
Plan for coming week:
- Expand API: Continue working on code to allow modules to declare widgets.
- Begin working on Google Gadgets module.
- Create embed widget settings page under Administer > Site Configuration and begin using it for various configuration options.
Challenges:
Time is running out, so I'm having to decide what features need the most attention in order to be completed by the end of SoC, yet I still want to perfect every detail.
2008-07-22
This week's progress:
- Added live preview to the widget edit page.
- Began implementing features to theme widgets. A widget can now be themed using any theme that has been enabled.
- Display type of a view can be selected.
- Views Arguments integration: Arguments can be passed from a widget to a view.
- Added autocomplete features for some Views arguments to make UI more friendly.
- Miscellaneous improvements to API and UI to handle new features.
Plan for this week:
- Continue improving live preview while editing widgets.
- Continue working on widget theme customization.
- Expand API: Introduce hook for modules to create their own widgets.
- Begin working on user-created (as opposed to admin created) widgets.
2008-07-15
This week's progress:
- Updated API and UI to integrate with views.
- Views can be added to a widget and are displayed properly.
- Display type of a view can be selected.
- Text fields are generated for each argument that a view accepts. This will allow arguments to be entered from the user interface and then passed to the view. These forms have no functionality yet.
- I made some functions to help the UI development. These functions help to easily add and remove elements to a form and rebuild it as AHAH requests occur.
Plan for this week:
- Continue adding features to UI, such as live preview of widgets as changes are made.
- Begin implementing features to customize the theme of a widget.
- Continue integration with Views module: Views arguments!
- Implement access control when adding blocks and views to widgets. Currently, anyone with "administer embed widgets" access can add any block or view to a widget, but they should only be able to add blocks or views that they have access to.
Challenges:
The modules are getting bigger and the tasks are getting more difficult, so dealing with bugs at this point can be more frustrating. But the features are becoming better and more fun. :)
2008-07-08
This week's progress:
- Prepared for midterm evaluations by cleaning up and commenting code and finished writing README.txt and handbook documentation.
- Moved Embed Widgets to its own section of the Module admin pages.
- Released alpha version of project for midterm evaluations.
- Researched and experimented with Views 2 integration.
- Added AHAH features to UI on "add/edit source" page.
- Added drag-and-drop features to UI on "add/edit widget" page, along with some other changes.
Plan for this week:
- Continue improving UI with more AHAH features :)
- Add integration with Views module.
Challenges:
Figuring out how to implement new user interface features such as AHAH and draggable table forms is fun, but a bit challenging. Still have some work to do on that, but it is coming along.
2008-07-01
This week's progress:
- Finished implementing JavaScript tab navigation in widgets using Tabs module.
- Made major changes to schema. Sources are now stored in their own table.
- Expanded API and UI modules to support schema changes.
- Moved code that gets content for widgets from IFrame module to API module. New API functions will be useful for other widget types.
- Re-organized IFrame module code to make it cleaner.
- Added documentation: Created README.txt and implemented hook_help().
Plan for this week:
- Make sure everything is ready for midterm reviews.
- Begin integration with Views module.
- Begin implementing features for customizing widget themes and end-user widget customization.
Challenges:
Nothing slowing me down yet, but some of the upcoming tasks will be challenging.
2008-06-24
This week's progress:
- Began implementing JavaScript tab navigation in multi-source widgets using jQuery UI.
- Began integration with Tabs module.
- Fixed bug: http://drupal.org/node/271916
- Implemented API hook that will allow add-on modules to register new widget types.
Plan for this week:
- Finish implementing jQuery Tabs navigation/integration with Tabs module.
- Implement features to allow other modules/developers to create widgets using API.
Challenges:
Figuring out the best way to integrate templates with Tabs module theme function. I think I have figured out a good way to do it, I just have to finish implementing it.
2008-06-17
This week's progress:
- Implemented new feature: Widgets are now composed of multiple sources. Tabs are used to navigate sources within widgets.
- Created a basic CSS theme for widgets.
- Created a demo/test site.
- Improved UI for multi-source widgets and adding/removing blocks as widgets.
Plan for this week:
- Improve API: Finalize implementation of hook to allow sub-modules to register widget types.
- Begin implementing hook that will allow other modules to specify widgets.
Challenges:
Making changes faster than my patches and code are being reviewed, so I'm not always sure I'm going in the right direction or implementing things in the best possible way. At least no coding challenges are holding me back at this point!
2008-06-10
This week's progress:
- Implemented blocks as IFrame widgets.
- Implemented pages (paths) as IFrame widgets.
- Began discussing/implementing functions will be useful in the API.
Plan for this week:
- Continue working on API: submit new patches for review.
- Continue discussing UI.
- Update UI and IFrame modules as functions are added to API.
Challenges:
Finding the best way to approach the UI. I'm going to stall my experimenting with the UI module. A best approach needs to be discussed and planned out.
2008-06-03
This week's progress:
- Upgraded existing embed widgets to Drupal 6.
- Re-factored code into separate modules: API, UI, and IFrame.
- Began redesigning user interface.
- Began implementing ability to provide Drupal blocks as widgets.
- Updated install file.
Plan for this week:
- Refine user interface and API.
- Refine how Drupal pages are embedded as iframe widgets.
- Finish implementing blocks as iframe widgets.
- Research/begin implementing Views as iframe widgets.
- Begin theming the content of iframe widgets.
- Research customizing widget theme with color module.
Challenges:
No major problems are holding me back yet. Still learning more about Drupal development everyday, so some days are slower than others.
2008-05-27
No coding was done yesterday, the official start date, as it was a holiday in the U.S. Today I decided that a good way to better familiarize myself with Drupal and with the existing Embed Widgets modules would be to upgrade them to Drupal 6. I was able to get the install files upgraded by implementing the new schema API. Changes to the menu system and Forms API are in place, but not entirely working at this point.
One challenge I have encountered is converting the existing phpTemplate "hack" to Drupal 6.
Task summary:
- Began upgrading embed widgets to Drupal 6.
- Updated menu system.
- Updated forms to comply with Forms API.
- Updated install files to work with schema API.
- Made some changes to database abstraction layer function calls.
- Updated Wiki
Plan for this week:
- Continue discussing and refining direction this project should take.
- Finish upgrading current code to Drupal 6.
- Begin refactoring the existing code by separating existing API, IFrame, and UI code.
Comments
I'd like to plan out this
I'd like to plan out this project by discussing with mentors and the community. This is my first time developing for Drupal and this is a big project, but I'm excited about it!
As I learn as much as I can before coding officially starts, I also want to nail down some specifications for this project. Hopefully laying out these specifications will produce a good amount of documentation along the way.
As you can see, I've started laying out the specifications. Let me know if I have the right idea and please give comments and suggestions!
This is excellent
This is excellent.
I myself have been busy researching about embeddable widgets and making them work seamlessly with the host site. This I hope will help you in designing the JavaScript Module, for example take a look a project i spun-off from the research: http://corruptedpartition.blogspot.com/2008/05/twitsnap.html
Use FF and FireBug to see how the script works.
The app itself doesn't look fabulous but it addresses the following:
- Dynamic loading of external CSS file
- Dynamic loading of external Javascript file
- Dynamic load an external content and modify the host site content dynamically! (Does not use IFRAME!). Also addresses crossdomain problem (bypass) and Internet Explorer's dreaded "Operation Aborted" error.
The idea here is to allow widget (view.module) communication with the backend server (services.module):
1. the widget tries to load dynamically a javascript while passing the data it wishes to send via URL.
2. Then the resulting javascript loaded dynamically will contain the javascript code to load the data back into the widget's properties or straight to DOM
3. resulting javascript loaded dynamically also invokes the widget's method to update it self.
4. widget is updated and cycle begins again.
Google Mashups
We might want to look at http://editor.googlemashups.com/ as well -- I just found out about that (in beta) project. Obviously, it's out of scope to add functionality, and of limited current value (as it's currently a closed beta), but will probably be important in the future. Also, it might serve as inspiration.
Aaron Winborn
AaronWinborn.com (my blog)
Advomatic, Web Design for Progressive Advocacy, Grassroots Movements, and Really Cool Causes
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
Embed Widgets
nedjo recently informed me that he's working on a similar project entitled "Embed Widgets": http://drupal.org/project/embed_widgets
He suggested that it may be worthwhile to merge the two projects and have me extend what he's done so far. His project description is a bit vague, but it sounds like he's doing something quite the same. What do you all suggest?
Need more info...
In general I think it's a great idea to work together with other people developing similar projects, rather than duplicating efforts. However, we need to find out a lot more about where nedjo sees embed widgest going. From my initial cursory look at the module it does seem to offer a great building block to start with.
Anyway, it is most definitely worth pursuing! Could you ask nedjo to come here and chat with us about it?
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Proposal for merging projects
Hi John,
To expand a bit on my email:
I've started Embed widgets with pretty much exactly what you're trying to do in mind. It's only a small ways along, but I think it may be a useful start for you. I'd be happy to serve as an informal mentor in addition to your current mentor(s).
There are a key difference though. Rather than focusing on Views, Embed widgets exposes any Drupal content (any page). My thinking: while views are good for a lot, eventually people will want non-view content and functionality in widgets, e.g. a login block, so best to build up front an architecture that supports any request (views included).
Also, so far, I've only implemented iframe embeds. I looked at the question of writing a widget as a Javascript client for Drupal. It seemed to make most sense for this to be a client of the Services module, http://drupal.org/project/services. It could and probably should be done, but we end up with a very different set of needs and solutions from working with iframes. With iframes, we can rely on Drupal's native functionality. We don't have namespace collision issues, etc. Our main challenge is not to produce content or functionality but rather to limit what is shown and what paths widget users can travel. A Javascript client is more complex in that we need to provide custom handling.
I've done no work yet on support for widget APIs (Facebook, OpenSocial, etc.).
A bit more on the approach I've taken in Embed widgets.
function _phptemplate_page(). This allows specialized output of a page without the regular theming (blocks, etc.). The default theme for a widget must be set to a PHPTemplate theme (that doesn't itself include afunction _phptemplate_page()),I'm not set on the current structure of embed_widgets and would be happy to have you refactor. I like your suggested structure of (a) a widgets API module, (b) a set of widget format modules (Javascript, iframe), (c) a set of external API modules (Google gadgets, Facebook, OpenSocial). I would add a widget UI module providing an admin UI to the widget API.
Concretely, merging projects would mean:
Then continue with your workplan. In general, my main concern is that you're taking on a lot. I'd suggest cutting it down to, e.g.:
Then you could take on additional widget APIs (Facebook, Google Gadgets) and Javascript widgets if there happens to be time after you've covered off what is already an ambitious workplan.
I've assigned you CVS access to embed_widgets. Perhaps you'd like to install and test the existing version, take a look at the code, and consider from there?
Nedjo
Project Scope
Thank you for the information, nedjo. I installed Embed Widgets and tinkered around with it and looked at the code. I do like what you've done so far and wouldn't mind refactoring and extending Embed Widgets.
Embedding pieces of a Drupal site other than those provided by views was something I had wondered about, but it was never mentioned in the original project proposal. It would seem very valuable to embed things like polls, newsletter subcription, and many other blocks provided by core or contrib modules.
I've been looking at the third party API's today. It seems to me that the purpose of the OpenSocial platform is to develop social applications that deal with friend lists, messages, pokes/nudges, etc. This type of interaction in Drupal requires a slew of contributed modules (buddylist, privatemsg). So, unless we were to create a module that provides an application/gadget that allows users to share Drupal nodes with friends, I'm having a hard time seeing why we're targeting OpenSocial. The OpenSocial platform does use the Google Gadgets API to embed these applications in various places. So from what I've read, the Gadgets API seems to be what we should be targeting as far as 3rd party integration.
The Facebook platform also seems to deal more with social interactions that place a widget somewhere on a user's profile. From what I can tell, a Facebook application must be created before it can place any sort useful widget on a user's page. That seems to be more within the scope of the Drupal for Facebook project.
Creating widgets that don't involve social interaction for social network platforms seems like a less useful aspect to the project. Drupal widgets seem more valuable in dispersing content in new places such as iGoogle or desktop sidebars. Someone please correct me if I'm wrong in these observations.
Also, I think the Netvibes platform, as mentioned in the original project discussion, looks promising as well: http://dev.netvibes.com/
In short, we'd be narrowing the project down to the API, user interface, IFrames, Gadgets API, and possibly NetVibes. We'd also be expanding away from Views and moving away from the complications of JavaScript.
What do my mentors think?
Sounds pretty good to me...
This sounds like a good modification of the original scope to me, though I'd like some more comments on the OpenSocial side of it. I too think that expanding this beyond views and focusing on the api and one or more implementations is a good idea.
I'm e-mailing Angie to see what she thinks, and if everything's cool with her, and with the other mentors, it's cool with me.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
I got the okay from Angie...
...so all we're waiting for is the other mentors, whom I'm sure will have only minor suggestions/additions. In other words, this change is a go. Can you update the wiki?
Also- we should figure out how to get rid of the Views as Widgets project page.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
My response (just so it's documented here)
I would say that (at this point especially), whatever makes the project more useful to the Drupal community as a whole, do that. I read nedjo's response and the idea of any PAGE as a widget as opposed to any VIEW sounds like a subtle but extremely powerful change. +1.
There's nothing official we need to change on Google's side for this. We just need to make sure that there's enough work for John to do, as he's using Nedjo's code as a base. We want to keep him nice and busy for 3 months. ;) I'll leave that to you and the rest of the mentoring team to determine.
Incidentally, I can delete the project once a suitable replacement is made.
Awesome!
nedjo-
thanks for the great writeup and the offer to help. I've e-mailed Angie and my co-mentors to elicit their opinions, but this seems great to me!
Would you have any objection to being listed as an actual co-mentor, rather than keep it informal? I don't think it would take any additional work on your part, but it would make it official and you would get a nice google t-shirt at the end if it went through.
Anyway, thanks again for stepping forward and for your help!
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Drupal 6?
Today I began updating the existing Embed Widgets module to Drupal 6. I did this more as an educational exercise than a design decision. It helped me dig deep into the code and familiarize myself more with Drupal programming. I learned a lot already and felt that I made quite a bit of progress.
With that being said, we do need to discuss which version of Drupal we'd like to develop this project for. It made be possible to produce versions for Drupal 5 and 6 as part of GSoC. I wouldn't be opposed to it if there is time, but I certainly don't want the process of making two versions to take away from making the best possible module for one version. Any thoughts?
+1 on D6
I would recommend D6, there is a significant enhancement on API and the way modules are loaded which addressed a lot of slowness in previous version. On that alone is my personal reason why i migrated most of my projects to D6.
Anyway im not betting that the SoC output would have a good performance (speed wise), the 'first' is always meant for learning -- so D6's improve responsiveness will help a lot in the initial usability rating of the project.
Finally by the time SOC ends I'm hoping D7 RC is almost available(?) and by next year, migration path to D7 would be easily achievable with a stable version available on D6.
Agreed...
a) I think you're going to have a lot on your plate getting the project done once, let alone twice. :)
b) By September, Drupal 7 will be around the corner soon.
c) Stuff like Views (which you might need to hook into) have changed dramatically since D5.
I'll third that...
I think that focusing on D6 is plenty of work already, and back-porting Views side of the project to Views 1 will be tons of extra work that could be better spend on making the module as powerful/flexible/pluggable/extensible as possible.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Updgraded
Well, I've upgraded the existing Embed Widgets module to Drupal 6. The pages inside the IFrame are not rendered correctly. In v5, they were stripped of the header, blocks, and sidebar. In v6, it displays everything. I may not spend the time to fix this as I'm looking at other ways to theme widgets besides nedjo's phptemplate "hack."
Otherwise, all the forms, menus, install, etc. is working.
Great work on the update;
Great work on the update; it's looking good. What are some of the other ways you're considering? Until I saw this module, I hadn't even considered the simple idea of just embedding a page in an IFrame, which is powerful just in itself.
Personally, I'd say to leave that as an option, but to also include some of your earlier ideas, such as embedding a specific View (and Panel?). Although that would obviously make the existing UI more complex than it already is.
I agree not to spend any time with the phptemplate 'hack' at this point, as some folks might find it useful to simply embed a page (although in reality, that would require some theme overrides to be useful on a practical level). I suspect that most uses, as I envision it, will want to go the route of the earlier discussion, such as embedding a View, which wouldn't require doing that.
Aaron Winborn
AaronWinborn.com (my blog)
Advomatic, Web Design for Progressive Advocacy, Grassroots Movements, and Really Cool Causes
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
Here are my current
Here are my current thoughts...
I agree, the current implementation of embedding a page isn't very practical or user friendly. It would be easier for someone who wants to embed an entire page to just use an iframe tag and enter the URL to the page as the source.
I'd like to have a default theme for a widget that can be easily customized through the UI. Something similar to the blocks on the right side of this page would work well. At the very least, each widget would have a title and a source. The source could be a page, a node, a feed, a view, or a block. The UI could be simplified by adding a simple "Make this embeddable widget" checkbox while editing a node, view, or block. Also, an "Embed this" link could be provided on any source that has the widget option enabled. Once clicked, the colors are customized and then the HTML or XML code is provided to copy and paste.
Something that would be nice would be the ability to create groups or lists of widgets by taxonomy. Corresponding navigation tabs would then be provided within the widget to switch between widgets. That way, a number of widgets could be provided in one "embedding".
I'm looking at the Printer-Friendly Pages module as a resource for IFrame widgets. It takes any Drupal path and re-styles it to a printer friendly page by visiting a URL such as www.mysite.com/print/path/to/page. For widgets, www.mysite.com/embed-widgets/iframe/path/to/page would render the page in a way that is suitable to be embedded as an IFrame widget.
I vote D6 myself Steve
I vote D6 myself
Steve
Blocks as Widgets
I made some promising progress today to implement any Drupal block as a widget. Since Views can be provided as blocks or pages, do we need to hook into the Views module to display views and widgets? It seems to me that we'll be able to accomplish that goal simply by allowing any page or block to become a widget.
Here's how I did it:
I made a menu callback like so:
embed-widgets/%embed_widgets/embed/iframe/block/%/%Then in the callback function...
$block = module_invoke($module_name, 'block', 'view', $delta);$output = "<div class=\"embedded-block\">\n";
$output .= "<div id=\"embedded-title\"><h2>".$embed_widget['title']."</h2></div>\n";
$output .= '<div class="content">'. $block['content']. '</div>';
$output .= "</div>\n";
print $output;
And, voila! Block content ready to be embedded as an IFrame. Of course, more work needs to be done, but I like the way this is looking. Any thoughts?
Nice start
Thanks for your work, this it's great to see the module progressing.
A main consideration when exposing data/content in new ways is to ensure we're not opening security holes. In this case, we need to ensure that the block data still have any access restrictions that apply for regular block viewing. This includes e.g. role access restrictions. The callback as it stands will load any requested block, whether or not the current user should have access to it.
Here's how I approached the problem in a (now deprecated) module called dyamicload (part of jstools, available in the 5.x dev version).
<?php/**
* Menu callback to return a rendered block in JSON format.
*/
function dynamicload_fetch_block($module, $delta) {
global $theme_key;
if (!isset($theme_key)) {
init_theme();
}
$region = db_result(db_query("SELECT region FROM {blocks} WHERE module = '%s' AND delta = %d AND theme = '%s'", $module, $delta, $theme_key));
$blocks = block_list($region);
if (isset($blocks[$module .'_'. $delta])) {
print drupal_to_js(array(
'result' => TRUE,
'content' => theme('block', $blocks[$module .'_'. $delta]),
));
}
else {
print drupal_to_js(array(
'result' => FALSE,
'content' => NULL,
));
}
exit;
}
?>
The key point is that we call
block_list(), rather than invoking the given module'shook_block()directly. This ensures that regular access restrictions apply. (To do so, we need to determine first the correct region to feed--hence the use of $theme_key.)Nedjo
Please consider using the issue queue
I think it would work best if you open a new issue on the Embed Widgets module for each new feature you're working on. Generate and post patches. Or, if that starts to hold you up too much, go ahead and apply your changes, but link to the viewcvs diff showing what you've done, e.g., http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/embed_widge....
Using the issue queue will help for feedback and review. It's also good practice, since after SOC it will be best to keep doing your development in the open, letting the community know about new features as they come.
Start as early as you can--before you do the coding. "I'm considering such and such a problem and thinking of approaching it like this..." That gives a chance for others to pipe in if they have early comments, or at any point as you draft and then apply the change.
Thanks for the tips! I'll be
Thanks for the tips! I'll be creating several issues to discuss various ideas.
http://drupal.org/project/issues/embed_widgets
FYI
I'm sitting down right now to review some of the patches in the issue queue right now.
FYI, I'm writing the last chapter for Drupal Multimedia, to be published this summer by Packt, and have decided to feature this module in that chapter. It's shaping up well, and I firmly believe it will be a transformative force in Drupal.
Aaron Winborn
AaronWinborn.com (my blog)
Advomatic, Web Design for Progressive Advocacy, Grassroots Movements, and Really Cool Causes
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
@jtsnow, It's really fun
@jtsnow, It's really fun reading your updates and seeing your quick progress :)
Alpha Release
Thanks, amitaibu. SoC has been a great experience so far. :)
Aaron, thanks for your support for this project so far!
I've released an alpha version for testing and for SoC midterms, so let me know what you think so far! The project has come a long way, but the most exciting things are yet to come!
Any way to get item #4 of specification included?
Hi John,
First of all, let me congratulate you early for a successful project. Ive been using this module in my projects internally and soon I'll be launching an SNS using this module!
I would like to congratulate also Alex for being such a great mentor, I hardly needed to follow up any of the mentoring stuff during the course of the SoC -- everything is done on time.
On my personal review, 90% of the specification requirements were delivered. However were on the last stretch on SoC and IMHO we can get to at least 95% by getting item #4 on the specification which would prove this module's viability to interact with other social networking platform.
Here is my suggestion:
1. Generate and FBML for Facebook using Iframe method: http://wiki.developers.facebook.com/index.php/Fb:iframe. You will need to wrap the embed to into another page since Facebook doesn't allow direct javascript code embed so that you end up generating a code similar to:
<fb:iframe src="http://localhost/path/embed-widgets/1/embed/iframe/fbml">where http://localhost/path/embed-widgets/1/embed/iframe/fbml is a wrapper for the code:
<div id="drupal-embed-wrapper"></div><script type="text/javascript">var DrupalEmbed = {..json here..};</script><script src="http://localhost/path/sites/all/modules/embed_widgets/embed_widgets_remote.js"></script>Its a quick to do task IMHO.
Another thing is generate an XML for Google Gadget which is super easy:
<?xml version="1.0" encoding="UTF-8"?><Module>
<ModulePrefs title="hello world example" />
<Content type="html"><![CDATA[
<div id="drupal-embed-wrapper"></div><script type="text/javascript">var DrupalEmbed = {..json here..};</script><script src="http://localhost/path/sites/all/modules/embed_widgets/embed_widgets_remote.js"></script>
]]></Content>
</Module>
See that i just wrapped the entire Iframe code with gxml, you can just then create a path for this like http://localhost/path/embed-widgets/1/embed/iframe/gxml.xml
And its done! 95-98% of the specs is completed! The rest of the specs like utilizing color module can wait but with #4 alone we have a killer module for social networks.
Rest assured after SoC I will be building lots of contributed modules based on embed widgets and sending you all the enhancement patches i have done privately :D
Again congrats to everyone.
Mabuhay!
-- Godie
Thanks for the suggestions!
Thanks for the suggestions! I nearly have the Google Gadgets module complete. It has been committed for about a week. I used a method similar to what you posted:
<?xml version="1.0" encoding="UTF-8"?><Module>
<ModulePrefs title="Widget Title" />
<Content type="url" href="http://localhost/embed-widgets/iframe/embed/1" />
</Module>
The problem with placing only the Iframe code in the gxml is that other Drupal JavaScript files are not included. With my method, all Drupal JavaScript and any JavaScript for contrib modules is included in the Google Gadget.
I will look into FBML since it may be just as easy, but right now my main challenge is refining the user interface and adding some features to allow users to create modules instead of only admins.
I look forward to seeing contributions from you!
John
Thanks, but...
I don't deserve any of the credit. John has been amazing, and on top of the ball on his own from day 1! If any of the mentors deserve a lot of credit it's nedjo, who graciously gave John control over the embed widgets project and helped with all of the most difficult technical issues.
Anyway, I'm extremely psyched that this has gone so well and I'm really looking forward to seeing this module in action and using it myself!
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Nice
Hey man,
I tried your demo and I really like it. I like the vision and see some serious potential with it.
Presenting a talk using Embed Widgets on Google Hackathon
I signed up to give a 5 minute lightning talk during the Philippines Google Hackathon regarding this project and its usage with OpenSocial tomorrow. I hope I get picked up :D