From: "Jacopo Cappellato" <[EMAIL PROTECTED]>
Adrian,
thanks for doing this.
Another thing I would like to discuss is to move the default location
for catalog and product images (uploaded from the Catalog application)
outside of the framework: from framework/images to somewhere in the
run
I think the reason images are kept there is because they are considered
"static content" and could be located on another server - for
performance reasons.
-Adrian
Jacopo Cappellato wrote:
Adrian,
thanks for doing this.
Another thing I would like to discuss is to move the default location
f
Adrian,
thanks for doing this.
Another thing I would like to discuss is to move the default location
for catalog and product images (uploaded from the Catalog application)
outside of the framework: from framework/images to somewhere in the
runtime folder.
This is just an idea, there could
I created a Jira issue for this and added one sub task -
https://issues.apache.org/jira/browse/OFBIZ-1867
-Adrian
Adrian Crum wrote:
Was anything done with this? Do we have a Jira issue or Wiki page?
-Adrian
Jacopo Cappellato wrote:
I think that Bruno's suggestion of creating a
"framework-c
Was anything done with this? Do we have a Jira issue or Wiki page?
-Adrian
Jacopo Cappellato wrote:
I think that Bruno's suggestion of creating a
"framework-candidate-release-x" version in Jira would be useful,
especially because there is no official (or even unofficial) list of
features/fixe
On Jun 26, 2008, at 4:03 PM, David E Jones wrote:
I like the idea for simple-method. One thing to keep in mind is that
many scripts are included "in-line" under the current call-bsh tag
rather than referred to as a file, so we'll have to have the type
attribute that was mentioned, and we
I like the idea for simple-method. One thing to keep in mind is that
many scripts are included "in-line" under the current call-bsh tag
rather than referred to as a file, so we'll have to have the type
attribute that was mentioned, and we should probably have it default
to "groovy" (and a
Jacopo,
Thanks for the clarification.
Let's see what other's has to say about it.
--
Ashish
On Thu, Jun 26, 2008 at 6:11 AM, Jacopo Cappellato <
[EMAIL PROTECTED]> wrote:
> Ashish,
>
> yes, what I meant that we could implement the new Minilang operation:
> "call-script"
>
> That operation could
Ashish,
yes, what I meant that we could implement the new Minilang operation:
"call-script"
That operation could then be used to replace the existing "call-bsh"
operation (that could be deprecated) and also it will be used to call
Groovy scripts.
Jacopo
On Jun 26, 2008, at 11:54 AM, A
Jacopo I liked the idea while we include the script file in Screen
Definition.
But if you will notice Jacques was talking about the Mini Lang call-bsh
replacement to call-groovy.
Please let me know your thoughts in reference to Mini Lang.
Thanks !
--
Ashish
On Thu, Jun 26, 2008 at 5:34 AM, Jaco
What if we just add a element instead?
We could then replace all the element to the new one.
The new one will use the file suffix to use the proper Processor
(.groovy, .bsh etc...)
And we may add an optional parameter for the type ("groovy", "bsh"
etc... that can be used if the script files
+1 for adding in minilang.
I can work on it in my free time as voluntarily if we would like to include
it in framework release.
Please let me know your thoughts on it.
--
Ashish
On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux <
[EMAIL PROTECTED]> wrote:
> +1 for Confluence
> BTW, should we n
+1 for Confluence
BTW, should we not add a in minilang (or did I miss something) ?
Jacques
From: "David E Jones" <[EMAIL PROTECTED]>
Like Jacopo hinted at, this is a community-driven effort and is
therefore a bit chaotic.
The main thing I was requesting from the community is to focus on t
Like Jacopo hinted at, this is a community-driven effort and is
therefore a bit chaotic.
The main thing I was requesting from the community is to focus on the
framework for a little while so we can stabilize and clean up the
framework in preparation for a binary release of it (leading tow
I think that Bruno's suggestion of creating a "framework-candidate-
release-x" version in Jira would be useful, especially because there
is no official (or even unofficial) list of features/fixes to go in
the framework... probably each of us has its own preferences.
Of course we should try to
15 matches
Mail list logo
