OSS

Grrrr.. SCS's the menu inconsistence is caused by the internal cache... and just realized my site has this problem too lol

The problem:
When the visitors visit a cached page which built by VIEW module(view page),  DHTML menu uses the menu settings from cache instead of the settings from visitor's cookie.  The result is that the menu is not consistent when the visitors go to a view page.

Bug Report: http://drupal.org/node/601178

Temporary solution:
Disable page cache... the drawback is slower load time.

Update:
Coded couple lines of javascript to control the menu base on the user cookie.

It has been a while since I posted my last FSOSS blog...  I finally started to work on FSOSS site lol... First thing I did is to get the new proposal form up...

The old form was ported from FSOSS 2007 site.  It's not Drupal site.  The form only provided couple basic function for registration.
Here is how it works: 
- Presenter submitted the form
- The form sent a notification email to the FSOSS staffs
- FSOSS staff had to create accounts and presentation/workshop node based on the data of the email... (This step is duplicated work... and waste of time... )

Therefore... A new form is born... I have rewritten the proposal submission form using Drupal's Form API in the past few days.... The last step is replaced by clicking checkboxes and buttons... lol
In the new form:
- Presenter submits the form

WOW.... Time flies...

Couple days ago..  Chris Tyler dropped me an email... it was about setting up FSOSS 2009 website... I was like... it's time for it already?!...

Anyway... fsoss.ca now redirects to FSOSS 2009 website...  there are not much contents...  the theme is same as previous...

First thing is to dupe whatever we have from 2008... then add the following new function...

Backend proposal registration automation
- The presentation and its speakers will register to the website upon submission.  An email will send to notify admins about the proposal.
- The presentation and speakers will wait for approval before showing up on the site.

I picked up Bug 253231 on Monday evening.   This bug is about validator resource handling.  It suggests that the validator should skip validation on .* resources(files, folders) by default.  Those who familiar with standard posix OS, *nix for example, probaby know what .* files are...   .* resources are hidden from viewing by default.   They are hidden in eclipse project explorer.  So there is no point to validate hidden files because they are not meant to be view/edit by a person.

The target milestone is 3.1.  Um... someone might be working on it.  I went to check the bug activity.  It got prosponed from 3.0.4 to 3.1.   Also, I came up a "solution" of this bug by the time i finished reading the bug report.  So I thought I'll give it a shot.

Ar... almost a month have passed since my last bug post...

Gary Karasiuk, the assgined developer of bug 2108101, replied to my newsgroup thread.  He confirmed that the validator only works with resources in workspace.   The point of this bug is to lift this restriction.

This feature will require massive changes as the validator was designed to work only with workspaces.   Also most of classes are tied to project as I mentioned before.  

I realized that I would not be able to complete this bug within short amount of time.  So I decided to pick up another validator bug on last Sunday.

I'll take about my new bug in next post........ soon....

Yesterday, I went through the help contexts xml files in org.eclipse.wst.validation.infopop.  Unfortunately, I found more evidence that solidify my view that the validator only works with project.  

Here is what I found:
"If you select a file or folder that is outside of the scope of a project, the rule will not be activated." - ValidationPrefs_HelpContexts.xml ( It appears in "WTP's validator preference page" -> "validator setting" -> "add rule" -> "folder or file name" -> "? (help)" )

I posted on WTP newsgroup about this issue.  Hopefully, I'll get a reply soon.
http://www.eclipse.org/newsportal/article.php?id=18299&group=eclipse.webtools#18299

I checked out the validator and validator.ui packages and played around with them in the pass two weeks...

I have discovered how manual validator works.  The validator item in popup menu(context menu) is set up in the plugin configuration.  ValidateMenuAction class is used as menu action class.  ValidateMenuAction calls ManualValidationRunner to start the validation and progress monitoring.  

But I couldn't figured what controls the visibility of "Validate".  The configuration is straight forward but it doesn't control the visibility of the menu item.

<!-- By saying "adaptable=true", this item will appear on both IProject and IJavaProject -->
   <extension
         point="org.eclipse.ui.popupMenus">
      <objectContribution

Bug 218101 is a feature request for the source editor.  The reporter wants to use the validator for casual editing, e.g. editing files that do not belong to any project.  But Eclipse currently doesn't support this feature.  You have to put the file inside a project in order to validate.  This feature is not available in I20081211-1908 build.  So.... I'll give this one a try...

FYI:

I have learned to identify multiple instances of Eclipse by looking at the perspective window or "about eclipse" in help.  But I found that inconvenience because it requires me to interact with the menu.   I want to be able to identify the Eclipse Instance by looking at the main window.   So I asked my friend, Google, to find a simpler way.  It returned this blog about "-showlocation" flag.   Guess what...  This flag does exactly what I want.   It embeds the workspace path into the titlebar.

If you want to know how to do it, visit this wiki page, Eclipse Tips...  This page will stores useful tips on using Eclipse... Oh.. Please share your tips on this page too!

Hi all. I'm here to kill some bugs in Eclipse WTP!!

Nice to meet you all.