date:20090126

Re: Issue with a framework dependency on the Party component

2009-01-26 Thread Hans Bakker

David,

see below

On Sun, 2009-01-25 at 23:00 -0700, David E Jones wrote:
 
 There are various things in the framework now that have general  
 infrastructure that applications can plugin to, and I think we could  
 follow that same pattern here.

if you can tell me how to insert 'action' and 'widget' statements in the
common/widget/commonscreens.xml decorators from a lower level component,
I am very happy to do that.

regards,
Hans

-- 
http://www.antwebsystems.com : 
Quality OFBiz support for competitive rates

Re: Split the framework/common component?

2009-01-26 Thread Jacopo Cappellato


On Jan 26, 2009, at 7:11 AM, David E Jones wrote:



The specific thing about messages is pretty simple... they should  
like in the lowest level (most depended on) component that uses  
them. If they are used in the party and common components, then they  
should go in the common component. Looking at the common component  
it is frustrating to see a number of labels/messages that include  
the word party as the common component doesn't know anything about  
parties (and should remain lower level and not know anything about  
parties even if we do split some of it into the applications).




Yes, I totally agree with you.

What to do with the common component is a bit of a tough call. I  
originally considered a lot of those data structures to be very  
generic and appropriate to put in a framework. There are lots of  
examples of low level tools including infrastructure for things like  
this, the Java APIs being a good example of one that includes things  
related to many of these.




For sure we still need a common component for the framework, but in my  
opinion it should contain only framework related common artifacts  
(entities etc...) and not applications related common artifacts (that  
should be moved into the new common component in the applications  
folder).


Some entities should definitely stay in the framework, like the  
Status* and Enumeration* entities in common and the WebSite and  
related entities in webapp, and I still think most of the other ones  
should too. There may be specific cases, but for the most part I  
think they are where they should be.




Well, in my opinion these entities would be good candidates for the  
new applications ' common component (unless they are used by other  
framework related entities, quite possible, I have  not checked this).
The main goal would be to have a framework as clean as possible, with  
no ERP/applications related entities in it (just user related and very  
tech entities).


Jacopo

I'll admit some are more dubious, so I'll gladly join in discussing  
specific entities. Some are really generic, but only used in one  
application component, like the CustomTimePeriod is only used in  
accounting, but it is a more generic concept so doesn't have to be  
only used there and could be reused for other things...


-David


On Jan 25, 2009, at 12:59 PM, Jacopo Cappellato wrote:

I really think it is time to start to think about splitting the  
common component into two components:
1) a common component to be placed into the applications folder and  
loaded before the other ones

2) a common component that will stay in the framework folder

All these labels, plus other ERP related artifacts, should then go  
in #1


In my opinion entities like Geo, CountryCode, KeywordThesaurus  
should not appear in a framework only distro.


But maybe I am off topic in this thread and I should create a new  
one.


Jacopo


On Jan 25, 2009, at 10:14 AM, risali...@gmail.com wrote:


Hi Hans,

it's ok to move it to the framework is they are more generics and  
they can be shared by all the components but in this case I think  
it's better to put the Common prefix on those labels.


Thanks
Marco


Il giorno 25/gen/09, alle ore 02:54, Hans Bakker ha scritto:


Hi Marco,

sure we can do this, however captcha itself is a framework  
function, but
at the moment only used in myportal... We will move the captcha  
messages

to the framwork

regards,
Hans

On Sat, 2009-01-24 at 22:22 +0100, risali...@gmail.com wrote:

Hi Hans,

I suggest to use the prefix MyPortal for those type of labels, I  
spent
a lot of days to cleanup all the wasted labels into OFBiz and I  
think

we cannot all use different standard to codify the labels.
And if it's possible do not use the underscore character in the  
labels

name could be more readable.

In my opinion for example CaptchaMissingError could be
MyPortalCaptchaMissingError or something similar to that.

If we do not follow this simple rule in two or three months the  
labels

will be completed wasted again.

What others thinks about that ?

Thanks
Marco


Il giorno 20/gen/09, alle ore 09:30, hans...@apache.org ha  
scritto:



Author: hansbak
Date: Tue Jan 20 00:30:41 2009
New Revision: 735965

URL: http://svn.apache.org/viewvc?rev=735965view=rev
Log:
first version of captcha, not perfect yet: multiple users
registering at the same time, image should be stored in 'runtime'
not working on windows. Another problem is what files to put
where.the captcha itself looks like a framework
feature...however the registration process needs the party
componentso let us know, we will correct it

Added:
ofbiz/trunk/framework/common/src/org/ofbiz/common/Captcha.java
(with props)
ofbiz/trunk/specialpurpose/myportal/widget/login.ftl   (with  
props)

Modified:
ofbiz/trunk/framework/common/widget/CommonMenus.xml
ofbiz/trunk/specialpurpose/myportal/config/MyPortalUiLabels.xml

Re: svn commit: r729396 [1/2] - in /ofbiz/trunk: applications/accounting/config/ applications/accounting/entitydef/ applications/accounting/src/org/ofbiz/accounting/invoice/ applications/accounting/sr

2009-01-26 Thread Jacopo Cappellato



On Jan 26, 2009, at 7:14 AM, David E Jones wrote:



I think of the BI stuff as being very like where we are going with  
themes and portal and such. The framework has infrastructure and the  
applications and such plugin to that infrastructure (through  
whatever means make the most sense).


For BI that would mean all of the tools (including UI) go in the  
framework, as long as they do not depend on anything in  
applications, and that data and services and more custom UI and so  
on go in the applications or specialpurpose components.


That will probably require splitting some of the POC stuff that  
Jacopo did into different components...




David, I totally agree, this is the plan. By the way, I already did  
the split, apart for the last service named quickInitDataWarehouse  
that I am not sure where to move... but it can be removed as well, for  
now it is just easier to test the BI features with it.


Jacopo



-David


On Jan 23, 2009, at 4:42 PM, Jacopo Cappellato wrote:

I would really prefer to keep it in the framework and just move the  
quickInitDataWarehouse (demo) service to somewhere else... any of  
the existing applications' components would be fine.


Jacopo

On Jan 5, 2009, at 2:11 AM, Bruno Busco wrote:


I have read David's post and I understood that having BI in
specialpurpose was not correct because it is a core module for an  
ERP.

From this I thought that having it in application could be ok and
still have the framework easily isolable.
-Bruno

2009/1/5 BJ Freeman bjf...@free-man.net:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think if you read davids comments included, that is the reason.
Framework you can have dependencies on,
Application you can not have framework depend on applications.

Bruno Busco sent the following on 1/4/2009 1:48 PM:

Hi Jacopo,
I have moved the bi folder from the framework to  
application (not

specialpurpose) and changed build.xml and component-load.xml.
It seems to me that it works well there.

Are there any specific reasons for having it in the framework  
folder

and not moving to application folder?

Thank you,
-Bruno

2009/1/4 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:

Hi Bruno,

these service calls are part of the quickInitDataWarehouse  
method that is
just a util method to simplify the BI setup for demo purposes:  
I know this
is not ideal and I agree that the method should be moved  
outside of the

framework.
But maybe for now we could leave it as is and just add a  
comment to it... it

is really useful in demos and testing.

Jacopo


On Dec 26, 2008, at 8:53 AM, Bruno Busco wrote:


That's fine,
we should then understand how to resolve some dependencies i.e.
service calls like:
   call-service service- 
name=loadAllProductsInProductDimension

in-map-name=inMap/
or
   call-service service-name=loadSalesInvoiceFact
in-map-name=inMap/
that are defined in catalog and accounting components that (I  
guess)

will not part of the framework.

-Bruno

2008/12/26 David E. Jones david.jo...@hotwaxmedia.com:
I think you misunderstand. The main bi stuff is just a tool,  
and really
belongs in the framework. Built on top of those tools are  
OOTB star
schema data models that can be used along with the OOTB  
operational data
model. Those belong with the base applications, along with  
reports that
are more generic in nature. Either way, most of the bi stuff  
is core to
OFBiz, and an important part of it (especially the star- 
schema and data
warehouse related parts), and is certainly not a peripheral  
add-on as

being in specialpurpose would imply.

-David


Bruno Busco wrote:
But maybe is better to move files using SVN in order to  
maintain

history...


2008/12/25 Bruno Busco bruno.bu...@gmail.com:

If needed I can send a patch for this right now.


2008/12/25 Bruno Busco bruno.bu...@gmail.com:

David,
I was trying to move the BI folder from framework to  
specialpurpose
and, once changed the build.xml and component-load.xml  
files,

it seems to build and work well.
Could we move it in order to simplify the framework-only  
deploy?

-Bruno

2008/12/25 David E. Jones david.jo...@hotwaxmedia.com:

The placement of BI in the diagram is based on the original
implementation, which was not part of the framework as it  
is now. BI

is
kind of a funny one and while there are tools for BI in the
framework,
and base data structures within the base applications, it  
can really

exist in applications, specialpurpose, or hot-deploy/add-on
components.

-David



Bruno Busco wrote:

Thank you David,
I did not see this page before and it helps very much.
I will take this as a Christmas present from you. ;-)


BTW, so this confirms that party should be out of the  
framework and

we
should remove all dependences on it from the framework  
(not adding

more).
Then I see that the BI also is out of the framework (and  
this is ok)
but in my framework-only installation that I got  
deleting the
applications and specialourpose folders from

[jira] Commented: (OFBIZ-2128) product image auto scale

2009-01-26 Thread Eric DE MAULDE (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667211#action_12667211
]

Eric DE MAULDE commented on OFBIZ-2128:
---

In this patch, the main thing is to save and keep the original image,
in order to plan future developments and API improvement.
Indeed from an original image, we able to work any changes.
We can implement services to modify all images in one time :
add a logo, resize, cut, compress ...

The current ImageIo.read(new File(filePath)) can't read some JPG images ?

What do think about these API :
JAI (Java Advanced Imaging from Sun
http://java.sun.com/javase/technologies/desktop/media/jai/ )
Imagero (free for non-commercial use, http://reader.imagero.com/ )

product image auto scale
-

Key: OFBIZ-2128
URL: https://issues.apache.org/jira/browse/OFBIZ-2128
Project: OFBiz
Issue Type: New Feature
Components: product
Affects Versions: SVN trunk
Environment: Linux Debian, OFBiz trunk rev. 737217
Reporter: Eric DE MAULDE
Assignee: Jacques Le Roux
Priority: Trivial
Fix For: SVN trunk

Attachments: productImageAutoScale.patch, screenshot-1.jpg

This change allows to auto-scale product image when a user upload an original
image.
The original image is saved into OFBiz.
Default dimensions of each image size type (small, medium, large, detail) are
defined in ImageProperties.xml
When an user uploads an original image, OFBiz resizes this image and creates
each related file.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-2140) Failure in create operation for entity [PartyRole]

2009-01-26 Thread Eric DE MAULDE (JIRA)

Failure in create operation for entity [PartyRole]
--

 Key: OFBIZ-2140
 URL: https://issues.apache.org/jira/browse/OFBIZ-2140
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: SVN trunk
 Environment: Linux Debian, OFBiz trunk 737660, PostgresQL 8.1
Reporter: Eric DE MAULDE
Priority: Blocker


When I load an ANT run-install with or not seed or extseed for the first 
time
There is an error in PartyRole entity
and I can't login admin with password ofbiz in backend

*** Error :

 cause -
Exception: org.ofbiz.entity.GenericDataSourceException
Message: SQL Exception while executing the following:INSERT INTO 
public.PARTY_ROLE (PARTY_ID, ROLE_TYPE_ID, LAST_UPDATED_STAMP, 
LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, 
?) (ERREUR: une instruction insert ou update sur la table � party_role � viole 
la contrainte de cl�
�trang�re � party_rle_role �
  Detail: La cl� (role_type_id)=(CONTENT_GUEST) n'est pas pr�sente dans la 
table � role_type �.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

45 matches

Mail list logo