Hmm, that might be problematic. The schedule (or at least the detailed
view) is actually composed of 2 layers: the bottom layer contains the
table with the timelines etc. and the top layer contains the actual
appointments, using absolute positioning. The problem is that mouse
clicks are caught by the top layer so you cannot determine in which
table cell the click occurred. Perhaps you could calculate the correct
time and day of week/month from the coordinates?
If that works, we could add more flexibility by providing a way to add
context menus to the schedule.
Example:
context menu for background:
- add appointment
- add vacation
------------------------------
- paste
------------------------------
- go to day view for this day
- go to today
context menu for appointment:
- delete appointment
- edit appointment
------------------------------
- cut
- paste
I don't think this would require API changes, just a couple of extra
attributes, or perhaps adding a subcomponent to the schedule, containing
the context menu, like this:
<s:contextMenu type="schedule|entry">
<s:menuItem action="..." value="add appointment" />
<s:menuItem action="..." value="add vacation" />
<s:separator />
<s:menuItem action="..." value="paste" />
</s:contextMenu>
In fact, that would be very cool :)
Jurgen
Peter Mahoney schreef:
I am looking to add the ability to listen for the user to click on a
day, or time label on the schedule. This could be really useful as
clicking on a day in the month or week view could automatically take
the user to the day view. Clicking on a time could open a "New
Appointment" page with the date and time correctly set. I hope this
can be achieved without too many changes, although I have not looked
into how exactly it can be done. Once I have it working, I will submit
a patch.
Peter
Jurgen Lust wrote:
I totally agree :)
I have just posted a patch for the last remaining open JIRA issue for
the schedule component, and I think it is now feature complete, so
the API won't change very much anymore.
I just want to change the default color theme to reflect the myfaces
website look and feel. That greenish thing is probably not much use
to anyone.
After that, I'll start working on the Planner component.
Jurgen
Sean Schofield schreef:
IMO schedule is getting close to emerging from the sandbox. It will
probably be the first component we promote once we get a new tomahawk
release and the commons refactoring behind us.
Sean
On 2/23/06, Andrew Robinson <[EMAIL PROTECTED]> wrote:
Yeah I know. I don't mind using it as unstable, I just want the core
to be stable. Under 1.1.1, the latest validateCompareTo is looking for
ResourceLoader, and hence stops my project from loading.
The two components I want are validateCompareTo and schedule for now.
From what others have said, it sounds like schedule is getting close
to becoming part of tomahawk. Tonight I'm going to try to rip the
validate compare to out of myfaces and into my source tree to try to
get it to work against 1.1.1. Hopefully schedule works in the 1.1.1
version (I see the code is in the sandbox.jar for 1.1.1) well.
-Andrew
On 2/23/06, Werner Punz <[EMAIL PROTECTED]> wrote:
Hi Andrew always have in mind that the sandbox is sort of a Tomahawk
unstable ...
anything in there can get a major overhaul between versions and to
the
worse might be pulled.
(although for most components it is very very unlikely)
Andrew Robinson schrieb:
I have a bit of a dilemma. I would like to have the stability of
MyFaces 1.1.1, but I'd like to use some of the new Sandbox
components
(like validateCompareTo) which are not in the 1.1.1 release and seem
to require the newest core of myfaces to work (validateCompareTo was
throwing class and method not found errors when I tried using it on
myfaces 1.1.1).
In the SVN branch, I find I come across many errors. The last one
was
a bad one. About a week ago t:commandButton tried to treat the
"action" property as a ValueBinding instead of a MethodBinding.
Any idea on the next scheduled release? (rc or beta would be nice
over
source control updates).
Thanks,
Andrew
