ttps://builds.apache.org/job/tobago-trunk/1173/])
TOBAGO-1357 - Removing Dojo DND calls from renderers (lofwyr:
http://svn.apache.org/viewvc/?view=rev&rev=1557677)
*
/myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/
[
https://issues.apache.org/jira/browse/TOBAGO-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Schnurpfeil resolved TOBAGO-1357.
-
Resolution: Fixed
> Removing Dojo DND calls from render
Udo Schnurpfeil created TOBAGO-1357:
---
Summary: Removing Dojo DND calls from renderers
Key: TOBAGO-1357
URL: https://issues.apache.org/jira/browse/TOBAGO-1357
Project: MyFaces Tobago
Issue
Some small codeparts from the myfaces jsf.js stem from dojo mainly 2-3
helper routines in _Lang.js and _Dom.js, they become less and less, but
nevertheless there still is a little bit in there. J4Fry that was more
or less the stuff from Ganesh and Alex which worked on the initial
version of
Hi
In theory yes, the javascript part of myfaces core contains portions
of code taken from dojo, and j4fry guys donated some code there too.
regards,
Leonardo Uribe
2011/12/12 Mark Struberg :
> s/shin/ship/ ^^
>
> lieGrue,
> strub
>
>
>
> - Original Message
s/shin/ship/ ^^
lieGrue,
strub
- Original Message -
> From: Mark Struberg
> To: myfaces-dev
> Cc:
> Sent: Monday, December 12, 2011 11:25 PM
> Subject: do we still use dojo?
>
> Hi!
>
> I came across a dojo.license which we still shin in our latest
Hi!
I came across a dojo.license which we still shin in our latest mf-2.1.5.
Same for j4fry.
Do we still use this stuff?
LieGrue,
strub
ter for dojo ajax requests
> --
>
> Key: TOBAGO-653
> URL: https://issues.apache.org/jira/browse/TOBAGO-653
> Project: MyFaces Tobago
> Issue Type: Sub-task
>
[
https://issues.apache.org/jira/browse/TOBAGO-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Weber resolved TOBAGO-543.
-
Resolution: Won't Fix
This issue is replaced by tobago-841.
> replace prototype with
[myfaces-example-simple-1.1.9] dojo examples (library import and / simple
integration) don't appear to with with Mojarra
Key: TOMAHAWK
Hi,
We are having a meeting on the dojo facelets with the J4Fry people
tonight in munich. As this might come to MyFaces you are invited to join
us. If you aren't in located munich, don't panic: I'll outline our
results tomorrow.
Best regards,
Ganesh
Ori
tions!
Use the mailing list instead. Infos are here:
http://myfaces.apache.org/mail-lists.html
No, there is no dependency on dojo...
> Trinidad Dependency on Dojo
> ---
>
> Key: TRINIDAD-1458
> URL: https://issues.apache.org/
Trinidad Dependency on Dojo
---
Key: TRINIDAD-1458
URL: https://issues.apache.org/jira/browse/TRINIDAD-1458
Project: MyFaces Trinidad
Issue Type: Task
Reporter: karthikeyan
Priority: Trivial
[
https://issues.apache.org/jira/browse/TOMAHAWK-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hazem Saleh deleted TOMAHAWK-1270:
--
> removing the dojo Ajax dependency from the PPRPanelGroup compon
Martin Marinschek schrieb:
I can certainly live with dojo components being in an optional,
plug-in subproject of Tomahawk - they should then however use Tomahawk
infrastructure, the generator-environment and work together with its
components.
As I said moving over the generator is basically a
Andrew Robinson schrieb:
I can see the point of that argument, but worry that putting heavy 3rd
party JS libraries into Tomahawk will steer people away from using it.
IMO, Dojo based components should either be (1) in a new MyFaces top
project, or in (2) a subproject of Tomahawk (i.e.
myfaces
I can certainly live with dojo components being in an optional,
plug-in subproject of Tomahawk - they should then however use Tomahawk
infrastructure, the generator-environment and work together with its
components.
regards,
Martin
On 7/10/08, Andrew Robinson <[EMAIL PROTECTED]> wrote:
&
I can see the point of that argument, but worry that putting heavy 3rd
party JS libraries into Tomahawk will steer people away from using it.
IMO, Dojo based components should either be (1) in a new MyFaces top
project, or in (2) a subproject of Tomahawk (i.e.
myfaces-tomahawk-dojo).
#2 has its
Hi Mario,
I do not fancy YACL (yet another component library). Really not. There
is some cool stuff in Werner's proposal, and I think it might be nice
if it is carefully integrated into tomahawk without breaking the other
stuff that is there. I do strongly think that we cannot afford the
community
Hi!
Werner Punz schrieb:
Martin Marinschek schrieb:
In any case, I remain -1 to add a new component library - I am sorry.
Ok I am going to postpone this discussion until I can showcase something
then we can start it over...
Hmm ... was Martin's -1 a veto or did he just express his opinion.
M
components over
we suddenly have two conflicting dojo versions in the sandbox
In any case, I remain -1 to add a new component library - I am sorry.
Ok I am going to postpone this discussion until I can showcase something
then we can start it over...
:-)
moved the old components over
>> we suddenly have two conflicting dojo versions in the sandbox
In any case, I remain -1 to add a new component library - I am sorry.
regards,
Martin
On Tue, 2008-07-08 at 21:52 +0200, Werner Punz wrote:
> Martin Marinschek schrieb:
> > Hi all,
> >
> > I am -1 for adding another sub-project.
> >
> > Put this into the sandbox - and use the new code-generator, please,
> > and upgrade the exis
Martin Marinschek schrieb:
Hi all,
I am -1 for adding another sub-project.
Put this into the sandbox - and use the new code-generator, please,
and upgrade the existing dojo components to the 1.1 version -
everything else will make us very unhappy in the end!
Well I will move over to the
Hi,
2008/7/8 Andrew Robinson <[EMAIL PROTECTED]>:
> +1 to subproject
>
> -1 to sandbox.
>
> IMO, Dojo should be separated from Tomahawk
+1 for that, but if i understand Werner correct his current
implementation depends on tomahawk.
Regards,
Volker
> and the sandb
+1 to subproject
-1 to sandbox.
IMO, Dojo should be separated from Tomahawk and the sandbox is part of
Tomahawk, not a play ground for all the different MyFaces libraries.
On Mon, Jul 7, 2008 at 2:47 AM, Ernst Fastl <[EMAIL PROTECTED]> wrote:
> Hi Werner,
>
> I think it would be
Hi all,
I am -1 for adding another sub-project.
Put this into the sandbox - and use the new code-generator, please,
and upgrade the existing dojo components to the 1.1 version -
everything else will make us very unhappy in the end!
regards,
Martin
On 7/7/08, Kito D. Mann <[EMAIL PROTEC
details.
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2008 3:32 PM
To: MyFaces Development
Subject: Re: Dojo discussion - opensourcing the jsf dojo components project
Hi!
Ok then those things are cleared up, now back to the original question
sandbox or own subpro
+1 for a subproject as well.
On Mon, Jul 7, 2008 at 10:40 PM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:
> On Mon, Jul 7, 2008 at 9:32 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> > Hi!
> >>
> >> Ok then those things are cleared up, now back to the original question
> >> sandbox or own s
On Mon, Jul 7, 2008 at 9:32 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
>>
>> Ok then those things are cleared up, now back to the original question
>> sandbox or own subproject?
>
> +1 for own subproject.
+1 as well
-M
>
> Any further influence with tomahawk/sandbox needs to be avoide
It doesn't make much sense to rewrite it to work as part of the
sandbox project, only to pull it back out as a separate project again,
especially since it's already stand-alone.
+1 as a separate project.
On Mon, Jul 7, 2008 at 3:32 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
>>
>> Ok th
Hi!
Ok then those things are cleared up, now back to the original question
sandbox or own subproject?
+1 for own subproject.
Any further influence with tomahawk/sandbox needs to be avoided.
These two projects are still waiting for a overhaul themself.
Ciao,
Mario
question
> sandbox or own subproject?
>
+1 to its own subproject for this feature, taking into account that this
dojo components uses its own code generator tool, and use a different dojo
version.
>
> Both options are fine for me, but with the sandbox I have to clearly
> make commen
the demos that mixing the controls with other dojo
based tomahawk controls is not possible for now...
On [EMAIL PROTECTED] Craig Russel (SUN)
agreed that a software grant is fine.
-M
On Mon, Jul 7, 2008 at 5:29 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I think it is fine here. My main reason for the incubator list was
> just b/c this project
> was completely developed offline.
Hi,
I think it is fine here. My main reason for the incubator list was
just b/c this project
was completely developed offline. So, it is (to me) a new project. That's all.
For me, a software grant would be pretty much enough.
-M
On Mon, Jul 7, 2008 at 5:03 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTE
Hi Simon,
On 7/7/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> It's great that people are thinking carefully about the right way to
> handle this new code. But after some pondering, I'm happy for it to go
> directly into a sandbox here and not through the incubator.
I would say so as well -
It's great that people are thinking carefully about the right way to
handle this new code. But after some pondering, I'm happy for it to go
directly into a sandbox here and not through the incubator.
My reasons are:
Incubation is necessary when a brand-new project is created, in order to
be s
Ok I dropped a mail in the incubator mailing list lets wait
for the answers.
Werner
Martin Marinschek schrieb:
Yes, definitely incubator should be kept in the loop. But I feel a
Grant should be enough, if it is part of the sandbox.
regards,
Martin
On 7/7/08, Matthias Wessendorf <[EMAIL PROT
Yes, definitely incubator should be kept in the loop. But I feel a
Grant should be enough, if it is part of the sandbox.
regards,
Martin
On 7/7/08, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
>> Well best probably is to ask there, but I dont think there should
>> be too much of a problem of g
> Well best probably is to ask there, but I dont think there should
> be too much of a problem of getting it in directly without
> having to go through the incubator, due to the nature of the code being
> developed 100% by me.
I am fine with that. But I just want to make sure everything is fine
an
Matthias Wessendorf schrieb:
Not sure if the development is outside of the apache community
the I wrote basically every single line of code so far myself.
but not under an Apache umbrella.
(Except for dojo)
The extensive table component which is pending, is a shared work
with all people
> Not sure if the development is outside of the apache community
> the I wrote basically every single line of code so far myself.
but not under an Apache umbrella.
> (Except for dojo)
>
> The extensive table component which is pending, is a shared work
> with all people involve
enough)
since it was developed outside of the Apache community,
this is something that needs
a) incubation
OR
b) software grant
Not sure if the development is outside of the apache community
the I wrote basically every single line of code so far myself.
(Except for dojo)
The extensive table
> So my question is, are we going to host it inside of myfaces as its own
> subproject or as part of the sandbox or maybe I can move the codebase over
> to its own project outside of apache (jsfcomp for instance might be a
> perfect place until the entire complib is matured enough)
since it was de
No decision yet...
I would call it extensions, or something alike not really dojo
maybe we add other frameworks as well in the long run.
Werner
Ernst Fastl schrieb:
If moving to sandbox complicates the process a lot then maybe it would
be the better idea to, as you initially suggested, start
If moving to sandbox complicates the process a lot then maybe it would
be the better idea to, as you initially suggested, start a "tomahawk-dojo"
migrate and move the dojo stuff in the sandbox to there and get rid of dojo
in the sandbox. Has there already been a decision if we want t
components to make tomahawk again more attractive for the end user
in times of RichFaces, ICEFaces, ...
just my 2 cents
Ernst
Ok adding it to the sandbox would mean that we break the existing dojo
based components a mixing of dojo 0.4 components and 1.1 components
would not work in the same pa
hawk again more attractive for the end user
in times of RichFaces, ICEFaces, ...
just my 2 cents
Ernst
On 7/7/08, Werner Punz <[EMAIL PROTECTED]> wrote:
> Hello everyone
>
> as some know, I have been working semi silently the last months in my
> opensource time on a jsf dojo lay
Hello everyone
as some know, I have been working semi silently the last months in my
opensource time on a jsf dojo layer which is rather extensive, it is a
thin layer on top of dojo currently encapsulating around 23-25 of the
existing dijit components
(around 98% of the dijit components)
I
removing the dojo Ajax dependency from the PPRPanelGroup component
--
Key: TOMAHAWK-1270
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1270
Project: MyFaces Tomahawk
Create a own JsonResponseWriter for dojo ajax requests
--
Key: TOBAGO-653
URL: https://issues.apache.org/jira/browse/TOBAGO-653
Project: MyFaces Tobago
Issue Type: Sub-task
Werner,
An implied restriction would be only 1 version of DoJo per webapp.
Backward compatibility is my main concern. I will upgrade to the latest
DoJo in implement in Tomahawk, but it will be the entire application not
a page at a time.
Paul Spencer
My application is using the Dojo in
Paul Spencer schrieb:
Werner,
I am excited to see you are planning to upgrade the DoJo support. I
would like to see support for multiple versions, including the one
currently in Tomahawk. The desired version to use for any project should
be configurable.
Ah Paul sorry for the second
Paul Spencer schrieb:
Werner,
I am excited to see you are planning to upgrade the DoJo support. I
would like to see support for multiple versions, including the one
currently in Tomahawk. The desired version to use for any project should
be configurable.
Hello Paul first thanks for the
Werner,
I am excited to see you are planning to upgrade the DoJo support. I
would like to see support for multiple versions, including the one
currently in Tomahawk. The desired version to use for any project should
be configurable.
Paul Spencer
Werner Punz wrote:
hello everyone
I just
Leonardo Uribe schrieb:
I would like to see how tomahawk directory looks like after the
modification, only to take this into account. One question is if dojo
components should be 1.1 or 1.2 compatible (the difference is on the
generation of component and tag classes), or both.
Well for
On Tue, Apr 15, 2008 at 12:08 PM, Werner Punz <[EMAIL PROTECTED]> wrote:
> hello everyone
> I just wanted to drop a short note, start a discussion here.
> I was busy the last few weeks regarding dojo after getting weblets 1.0 out
> of the door.
>
> Well here is a
hello everyone
I just wanted to drop a short note, start a discussion here.
I was busy the last few weeks regarding dojo after getting weblets 1.0
out of the door.
Well here is a plan. As you all know we currently have dojo in Tomahawk,
well the main issue is, this is a huge dependency.
I
i already did this, did not work.
2008/1/26, Wendy Smoak <[EMAIL PROTECTED]>:
> On Jan 26, 2008 11:30 AM, Volker Weber <[EMAIL PROTECTED]> wrote:
>
> > How can i make maven-war-plugin put the dojo.zip into WEB-INF/lib?
> >
> > i tryed
> >
> >
On Jan 26, 2008 11:30 AM, Volker Weber <[EMAIL PROTECTED]> wrote:
> How can i make maven-war-plugin put the dojo.zip into WEB-INF/lib?
>
> i tryed
>
>
> org.dojotoolkit
> dojo-release
> 1.0.1
> zip
> runtime
>
>
&
How can i make maven-war-plugin put the dojo.zip into WEB-INF/lib?
i tryed
org.dojotoolkit
dojo-release
1.0.1
zip
runtime
and installed it to local repository, but it ended not in the war.
i need to remove the tag and reinstall it as jar to get it in
On Jan 26, 2008 10:00 AM, Volker Weber <[EMAIL PROTECTED]> wrote:
> I'm going to try out if we can use the zipped dojo as a dependency,
> even if its not in a maven repos, instead of shipping it unpacked in
> the theme jar.
As long as the license permits, we should be abl
I'm going to try out if we can use the zipped dojo as a dependency,
even if its not in a maven repos, instead of shipping it unpacked in
the theme jar.
I think it should be no problem for the TobagoResourceServlet to
deliver the dojo files from the zip archive.
Regards,
Volker
2
:-)
I mean in a public maven repos.
2008/1/26, Matthias Wessendorf <[EMAIL PROTECTED]>:
> http://download.dojotoolkit.org/release-1.0.2/dojo-release-1.0.2.zip
>
> http://download.dojotoolkit.org/release-1.0.1/dojo-release-1.0.1.zip
>
> http://download.dojotoolkit.org/relea
http://download.dojotoolkit.org/release-1.0.2/dojo-release-1.0.2.zip
http://download.dojotoolkit.org/release-1.0.1/dojo-release-1.0.1.zip
http://download.dojotoolkit.org/release-1.0.0/dojo-release-1.0.0.zip
see: http://download.dojotoolkit.org/
On Jan 26, 2008 7:56 AM, Volker Weber <[EM
Hi,
i also would prefer a dependency.
A dojo-.zip where fine, but afaik there isn't one public available.
I think we should, as long as we ship dojo with tobago, include all
stuff except tests and examples.
Regards,
Volker
2008/1/26, Matthias Wessendorf <[EMAIL PROTECTED]>
jetty's comet example does it similar;
the only ship what they really want (comet)
-M
On Jan 26, 2008 1:36 AM, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I think we don't don't need all the dojo stuff.
> I would prefer a dojo dependency and u
Hello,
I think we don't don't need all the dojo stuff.
I would prefer a dojo dependency and unpack the parts we need currently.
Regards
Bernd
Arvid Hülsebus schrieb:
> Hello,
>
> Do we really need all the Dojo sources in the standard theme? The jar is
> now a whopping
Hello,
Do we really need all the Dojo sources in the standard theme? The jar is
now a whopping 4717 kb.
We even package the Dojo unit tests. Now you can run them from your
favorite Tobago app -- like in the address book:
http://localhost:8080/org/apache/myfaces/tobago/renderkit/html
Hazem Saleh schrieb:
Hello Gerald;
Actually Dojo 1.0.0 has many nice stuff :).
I will follow your idea; making local development till Werner makes the update.
Thanks very much.
Sorry for not updating so long on this issue, the main problem I face
simply is time, I have plans to move upwards
change a minor change?
I would like to release 1.0.13 in two weeks.
> replace prototype with dojo as underlying ajax library
> --
>
> Key: TOBAGO-543
> URL: https://issues.apache.org/jira/br
replace prototype with dojo as underlying ajax library
--
Key: TOBAGO-543
URL: https://issues.apache.org/jira/browse/TOBAGO-543
Project: MyFaces Tobago
Issue Type: Improvement
Hello Gerald;
Actually Dojo 1.0.0 has many nice stuff :).
I will follow your idea; making local development till Werner makes the update.
Thanks very much.
On Nov 16, 2007 3:04 PM, Gerald Müllan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> tomahawk actually works with the pretty outd
Hi,
tomahawk actually works with the pretty outdated dojo 0.4.1 version.
As I know, dojox was introduced afterwards.
Werner will do the update to 1.0 the next weeks, so I think you have
to wait with sandbox work until the migration has been finished.
But this doesn`t prevent you from
Hi Guys;
Just a small question;
Can we use extended Dojo library (Dojox) for developing
components in sandbox project ?
Thanks very much.
--
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog
Luca
I think the features you have developed for the schedule component would
be an excellent addition. However, the use of dojo causes me problems as
previous attempts to use dojo components showed it requires Javascript
to be loaded in the HEAD section and possibly in the BODY onload. I am
Hi All,
I've modified schedule component for add dnd support and resize
capabilities to entries throught dojo
(http://mail-archives.apache.org/mod_mbox/myfaces-dev/200705.mbox/browser
and http://www.mail-archive.com/dev@myfaces.apache.org/msg22990.html).
Actually in developers mlis
Werner Punz ha scritto:
Not good, can you encapsule the problem down to a single require so that
I can check the affected files for a typo which has introduced the problem?
The code that introduce the problem is the following one: