Hi Joshua,
D'oh, pressed the wrong keyboard shortcut and sent the previous
version too soon :-/
Since it could be a while before I'm able to make a significant
code contribution, I'll reply to what can be done right away. :)
Even a small one is very welcomed. For example, adding the
addTransformer capability with javadocs and tests relieves the rest
of the RIFE contributers from a hour or two of work. Every small bit
helps. Actually, it's better to contribute with small chunks.
Evaluating large contributions takes a lot of effort and often gets
postponed.
Image transform-wise, I've run into a situation (twice now) where
I set a 'width' or 'height' value, but the orientation of some of
the images is opposite which causes it to be scaled incorrectly
(i.e. both 1200x1600 images and 1600x1200 images should use the
same scaling ratio but simply setting a width or height doesn't
give this result), so I created a transformer which uses
attributes 'short-edge-length' and 'long-edge-length', which does
just what I want. Yay! :)
I wonder if this class that you added to the wiki should be
included into RIFE and use a content attribute to make the CMF to
adopt it. What do you think?
I think it's a good complement to the 'width' and 'height' setters,
so yeah, it would be a useful item to have in the CMF.
Would you mind adding this as a contribution then? Don't forget that
it needs javadocs and tests also. Additionally, it would be good to
add this to the wiki section of the CMF page. (you could reference
the page you already wrote and remove the code from there once your
contribution has been added to the RIFE repository)
Before I go on and talk about RIFE, I'll say that I'm still a
little fuzzy on the workflow for how an image (file) goes from
the temporary upload directory through the transformers, validator
(s) and into the database.
Does this answer your question?
http://rifers.org/wiki/display/RIFE/Content+management
+framework#Contentmanagementframework-2
That document is really helpful, and I spent some time looking at
it (and will be spending more), but what I was referring to is how
some of the items get instantiated, then get referenced, and
finally get invoked. That document shows what happens ultimately,
but the actual sequence of class instantiations, references, and
then method calls is not as straight-forward. I think it will just
come from spending more time with it. :) You are also making heavy
use of Java 5.0 features too (which is great), which I'm still
coming up to speed on, so that's something else for me.
Honestly, if you want detailed information of what goes on exactly, I
suggest you simply step through the process you're interested in with
a debugger on the RIFE sources. It sounds that this will give you the
exact information that you're looking for.
MimeType: Yes, making the constructor public would allow
additional MimeTypes. Would it also allow overriding the static
MimeTypes?
It should. Can you please add a Jira issue for this?
Done. Suggestion: Add a 'cmf' component to Jira. I filed it in
Unknown, and against 1.4 (since that's what's I'm using), and
marked it bite-size with the assumption that the only change is to
make the constructor protected or public. I'll leave it to you to
change make any relevant adjustments.
Thanks! I added the cmf component and scheduled the issue for 1.7 the
latest. (if someone else picks this issue up, could be you, then it
can move up to 1.6)
Haha! :) I think the ConstrainedProperty API could be modified to
have an 'addTransformer(ContentTransformer)' method. This would be
a list of transformers, ordered by the call to addTransformer().
Example:
[in the MetaData class]
addConstraint(new ConstrainedProperty("imageMedium")
.notNull(true)
.file(true)
.editable(false)
.mimeType(MimeType.IMAGE_JPEG)
.contentAttribute("long-edge-length", 240)
.addTransformer(new PhotoScalingImageTransformer())
.addTransformer(new GreyScaleTransformer()))
);
This would result in 2 transformers being added to a list of
transformers to be executed for the 'imageMedium' property. They
would be executed in order, and each determine their activity based
on the provided attributes. The example above could represent a
flow which then scales the image by the longest edge, then converts
the scaled image to greyscale.
The existing ConstrainedProperty.transformer() method could be
modified to call the addTransformer() method, making the whole
thing backwards compatible.
I think that this is an excellent idea, go for it!! ;-)
As I think about it, teasing out the image conversion (from non-jpg
to jpg) will be more difficult, so, I'm just leaving it as is for
this discussion. :)
Take care and thanks for your excellent ideas!
Best regards,
Geert
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
