You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Akmal Sarhan <as...@byteaction.de> on 2004/11/30 09:39:27 UTC
2.3.1 thoughts
Hi all of Turbine developers
these are the things that crossed my mind so far in the migration to
2.3.1
-extended user:
according to what I have been experimenting so far, the extended user
HAS to have a db table that _IS_ _NOT_ called TURBINE_USER. otherwise
the extra columns will not be added to the db (why?). this means that we
have to rename our TURBINE_USER to eg. EXTENDED_USER . but what if we
don't (can't) do that?
-FileItem: now the fileupload package is used but I still have problems
compared to the home-brewed FileItem before:
getName() sometimes get the whole path depending on the handling browser
and I have to take care of that myself. I expect that to be handeld in
the implementation.
data.getParameters().getFileItem("file") will always return a non Null
value even if no file is selected.
-is there a good reason why TorqueUser and TorqueGroup
do not implement Retrievable so we can use them for our intake forms.
other than that we are very happy using 2.3.1 and we would be even happier if the Hibernate stuff could be pushed forward in the next release
so we could have an example of 2.3.x with only hibernate or with only torque.
best regards
Akmal
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: 2.3.1 thoughts
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
When we have the SVN in place, we can simply move it out of the
turbine.jar for 2.3.<mumble> (it is a component for 2.4 anyway), thus
getting closer to a "non-torque" turbine jar.
Regards
Henning
On Tue, 2004-11-30 at 15:03, Eric Pugh wrote:
> We should kill that scheduler officially.. It doesn't work well, and there
> are at least two other implementations out there. Jcrontab:
> http://jcrontab.sf.net has an Avalon component wrapper and in Fulcrum is a
> quartz based scheduler component. Either should get your energy.
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
--Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: 2.3.1 thoughts
Posted by Eric Pugh <ep...@upstate.com>.
We should kill that scheduler officially.. It doesn't work well, and there
are at least two other implementations out there. Jcrontab:
http://jcrontab.sf.net has an Avalon component wrapper and in Fulcrum is a
quartz based scheduler component. Either should get your energy.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: 2.3.1 thoughts
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Akmal Sarhan <as...@byteaction.de> writes:
>Hi all of Turbine developers
>these are the things that crossed my mind so far in the migration to
>2.3.1
Hi,
>-extended user:
>according to what I have been experimenting so far, the extended user
>HAS to have a db table that _IS_ _NOT_ called TURBINE_USER. otherwise
>the extra columns will not be added to the db (why?). this means that we
>have to rename our TURBINE_USER to eg. EXTENDED_USER . but what if we
>don't (can't) do that?
Sure about this? Did you let the old security schema lying around?
This _should_ work with TorqueSecurity, because the additional columns
are pulled in through reflection. Obviously you must change the
package of the peer classes, though. :-) The only really hard coded
names are TURBINE_USER_GROUP and TURBINE_GROUP_ROLE_PERMISSION.
>-FileItem: now the fileupload package is used but I still have problems
>compared to the home-brewed FileItem before:
>getName() sometimes get the whole path depending on the handling browser
>and I have to take care of that myself. I expect that to be handeld in
>the implementation.
>data.getParameters().getFileItem("file") will always return a non Null
>value even if no file is selected.
Hm. This works for me (through intake):
--- cut ---
Group grp2 = IntakeHelper.get(data, context, "Image");
String fkey = grp2.get("Image").getKey();
FileItem[] fi = data.getParameters().getFileItems(fkey);
if (fi != null && fi.length > 0)
{
byte [] img = fi[0].get();
if (img != null && img.length > 0)
{
[... now we have an image ...]
}
}
--- cut ---
>-is there a good reason why TorqueUser and TorqueGroup
>do not implement Retrievable so we can use them for our intake forms.
Jein. The one that Eric quoted was a bit terse, but basically, I
wanted to avoid implementing getQueryKey() and setQueryKey() thus
locking you into an implementation. If you need this, just extend the
objects and add the methods (yes, I already stumbled over that one,
too).
> other than that we are very happy using 2.3.1 and we would be even
> happier if the Hibernate stuff could be pushed forward in the next
> release so we could have an example of 2.3.x with only hibernate or
> with only torque.
Wanna help? I put my current Turbine 2.3.x compatible Hibernate
Service and Hibernate Security Service at
http://www.apache.org/~henning/hibernate-security-service-2864.tar.gz
http://www.apache.org/~henning/hibernate-service-2864.tar.gz
This stuff is undocumented, still has the wrong package names
(de.intermeta instead of org.apache.turbine) and needs some
makeover. But it works, it is intended to be put into "turbine
addons", once we have moved to SVN and just needs someone with time to
write some docs and work on the java docs. It does have quite a number
of Unit tests and works in a production environment 24/7 for months now.
Alternatively, someone that is interested in this, might want to make
a small project out of this and hire a Turbine developer (hint,
hint... ;-) )
I currently have no voluntary driven intentions to move the scheduler
service to Hibernate.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: 2.3.1 thoughts
Posted by Akmal Sarhan <as...@byteaction.de>.
Hi,
Am Di, den 30.11.2004 schrieb Eric Pugh um 13:01:
> Use the now release Hibernate based Fulcrum Security. There is also a
> Fulcrum Security adapter to hook it into the 2.3.x Turbine framework.
> Avoids all the Torque nastyness...
> >
is there any examples of howto
> Not sure I quite understand this.. Are you saying that you would return a
> File() object even if it doesn't exist? And the getName, what are the
> differing return values?
> >
yes if the form is multipart it always returns an object and the
getName() returns sometimes e.g c:\myfile or just myfile as a name but
this a known issue with some browsers e.g IE and should be handled
accordingly. I'll try to submit a patch
> > -is there a good reason why TorqueUser and TorqueGroup
> > do not implement Retrievable so we can use them for our intake forms.
> The reason for not implementing retreivable was so TorqueUser woulnd't be
> tied to Intake. But you could just extend TorqueUser and implement
> retrevable there...
well, that is exactly what I had to do but I do not like to _EXTEND_ I
always like to implement ;-)
> However, note that in Turbine 2.4 this is all gone in
> favor of Fulcrum Security.
> >
looking forward
> I'll finish up with a recommendation that you 1) look at using Turbine 2.4,
> 2) send in patchs for things that bother you. Turbine is a community based
> effort, and as such you can directly affect it's evolution! I think that if
> you are finding that Torque isn't working for you, and you want to use
> Turbine, then Turbine 2.4 Milestone
is there an up-to-date howto available for migrating Torque/Turbine2.3.x
applications to 2.4
> 1 will probably work for you. I am
> using it w/ Fulcrum security very successfully. Turbine 2.4 Milestone 2
> will probably be released soon, mainly updating the dependencies to the
> various released Fulcrum components.
>
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
> !EXCUBATOR:41ac6172299271532621537!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: 2.3.1 thoughts
Posted by Eric Pugh <ep...@upstate.com>.
Hi Akmal,
Thank you for your thoughts, this is a very useful email! I appreciate
getting feedback of this nature. I've put some comments in:
> -extended user:
> according to what I have been experimenting so far, the extended user
> HAS to have a db table that _IS_ _NOT_ called TURBINE_USER. otherwise
> the extra columns will not be added to the db (why?). this means that we
> have to rename our TURBINE_USER to eg. EXTENDED_USER . but what if we
> don't (can't) do that?
Use the now release Hibernate based Fulcrum Security. There is also a
Fulcrum Security adapter to hook it into the 2.3.x Turbine framework.
Avoids all the Torque nastyness...
>
> -FileItem: now the fileupload package is used but I still have problems
> compared to the home-brewed FileItem before:
>
> getName() sometimes get the whole path depending on the handling browser
> and I have to take care of that myself. I expect that to be handeld in
> the implementation.
> data.getParameters().getFileItem("file") will always return a non Null
> value even if no file is selected.
Not sure I quite understand this.. Are you saying that you would return a
File() object even if it doesn't exist? And the getName, what are the
differing return values?
>
> -is there a good reason why TorqueUser and TorqueGroup
> do not implement Retrievable so we can use them for our intake forms.
The reason for not implementing retreivable was so TorqueUser woulnd't be
tied to Intake. But you could just extend TorqueUser and implement
retrevable there... However, note that in Turbine 2.4 this is all gone in
favor of Fulcrum Security.
>
> other than that we are very happy using 2.3.1 and we would be
> even happier if the Hibernate stuff could be pushed forward in
> the next release
> so we could have an example of 2.3.x with only hibernate or with
> only torque.
I agree.. The hibernate stuff will probably be in Turbine 2.4.
I'll finish up with a recommendation that you 1) look at using Turbine 2.4,
2) send in patchs for things that bother you. Turbine is a community based
effort, and as such you can directly affect it's evolution! I think that if
you are finding that Torque isn't working for you, and you want to use
Turbine, then Turbine 2.4 Milestone 1 will probably work for you. I am
using it w/ Fulcrum security very successfully. Turbine 2.4 Milestone 2
will probably be released soon, mainly updating the dependencies to the
various released Fulcrum components.
Eric Pugh
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org