[solved]longtext, service.xml and servicebuilder.xml ?

[Axel Möschl, modifié il y a 16 années.]

Hello,

i want define longtext and not varchar(75)(String) in the service.xml for the servicebuilder. O.k. it seems it is not possible???

In your portlets, for Example Shopping - ShoppingItemField field description and values_, you make the same what i want, BUT this is not possible with the service.xml and servicebuilder .
Now, i can only define String and will get varchar(75).

How do you do it or what is the right way?

Axel

[Ray Augé, modifié il y a 16 années.]

> i want define longtext and not varchar(75)(String) in the service.xml
> for the servicebuilder. O.k. it seems it is not possible???
>


- Locate the file web-impl/classes/META-INF/ext-model-hints.xml

- Locate the specific entity and field..

- Add the model hints to make the field larger/smaller, etc...

- Re-run servicebuilder

e.g.

		<field name="description" type="String">
			<hint-collection name="TEXTAREA" />
		</field>

look in portal-impl.jar!/META-INF/portal-model-hints.xml for many
examples..

And yes, this file influences the tables/columns generated. So make sure
to rebuild after adjustment.

[Axel Möschl, modifié il y a 16 années.]

Hello Ray,

haaa.. , thanks. This is exactly what i want.
O.k. i think i must study the creationprocess/servicebuilder a little bit more.

Thanks Axel

[Glenn Powell, modifié il y a 16 années.]

Hello,
This process seems to be a little messy. You have to edit a generated (modified) file in order to get your hints in the service. This is very annoying if you want to do a clean rebuild of all or some of the services. You cannot simply delete the ext-model-hints.xml file, but instead have to go thru and edit by hand, removing only the un-altered portions.
The hope may be that you will never have to do this, but the ideal is usually not the reality. If you remove or rename some fields in a service model which already have modified hints in the XML file, then you have to remove/rename those fields by hand.
This also means that this file must be checked into source control, which is never the desired paradigm for generated files.

There are several of these such "paradigm breaks" in Liferay. Another is the creation of tables in the generated SQL scripts to handle the "mapping-table" attribute of columns in service.xml.
I have already dealt with this one locally by changing ServiceBuilder (a very simple modification), but I'd hope to see that change implemented in future Liferay releases.

As for the hints, I will once again modify ServiceBuilder to generate these hints from the service.xml, but it will also require changes to the service.xml dtd which I'm not very enthusiastic about.

Are these improvements something that can be anticipated in future releases?

[Ray Augé, modifié il y a 16 années.]

These hints are also used by the display logic which renders a field
using our display beans, like when we use

<liferay-ui:input-field ... />

Hints need to be stored somewhere in a config file,
*-model-hints.xml is that file. So, we use this single file for
affecting both the generated SQL and the rendering logic.

[Glenn Powell, modifié il y a 16 années.]

Ray Augé:

Hints need to be stored somewhere in a config file,
*-model-hints.xml is that file. So, we use this single file for
affecting both the generated SQL and the rendering logic.

But isn't this file also generated by the ServiceBuilder process? Shouldn't the hints be defined with the rest of the service in the actual service.xml files?

[Ray Augé, modifié il y a 16 années.]

> But isn't this file also generated by the ServiceBuilder
> process? Shouldn't the hints be defined with the rest of the service
> in the actual service.xml files?


Yes, but your changes persist.

[Fuad Efendi, modifié il y a 15 années.]

I understand now why the same tag generates TEXTAREA or INPUT etc... Great, thanks!

<liferay-ui:input-field model="<%= JournalArticle.class %>" bean="<%= article %>" field="description" />

[jigs vachhani, modifié il y a 15 années.]

I had one question. this change was reflecting when i added hints in /classes/META-INF/ext-model-hints.xml i.e. in classes folder. But when i did change in src, it got replaced with the original one. since we only make changes in src, how come for only this file we make change in classes. please clarify. thanks in advance.

[Ray Augé, modifié il y a 15 années.]

whenever you modify the model-hints files, make sure to run the compile target before your service rebuild.

i.e. [tt]ant compile build-services[/tt]

[Johns Abraham, modifié il y a 12 années.]

For me VARCHAR(length), STRING and TEXT types are possible with ext-model-hints.xml.
Is it possible to modify a database field with type LONGTEXT?
If yes, then how can I modify the ext-model-hints.xml for this change?
Thanks, Johns

[Avinash R, modifié il y a 10 années.]

Hello Ray,

I'm with Glenn's POV, the generated file shouldn't be modified manually.

But that being said, shouldn't this be filed as a bug/enhancement? or has it already filed?

[David H Nebinger, modifié il y a 10 années.]

Avinash R:

But that being said, shouldn't this be filed as a bug/enhancement? or has it already filed?

Neither. It is not a bug, and most of us don't see it as a required enhancement...

Right now, it is fairly easy to modify the service.xml file and build the services. Everything gets flushed out, including the model-hints that defines type stuff. So you, the developer, do not have to remember to modify model-hints just to build services.

After the initial build, you're free to change types/sizes/whatever on model-hints, and those changes persist across future service.xml changes.

Personally, I never let service builder create my tables/columns. Not because it can't, but because I have finer control over the DDL (can determine my own FKs, indices, not-nulls, permissions, etc.) and I also have a DBA that wants to handle all creation stuff.

So I just use service.xml and ignore model-hints as it is irrelevant (it's not like SB verifies that strings are only 75 chars, it just uses it for the DDL during creation). I'd hate to have to also do a model-hints file just to bind to my existing table...