Akmal Sarhan <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] +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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
