Forums / General / ezFloat Datatype not searchable?

ezFloat Datatype not searchable?

Next topic

Author	Message
Christian Rößler	Wednesday 17 March 2010 8:49:16 am Hy Community, today i faced a problem with ezFloat datatypes and searching those. Is there any reason why the datatype ezFloat is not searchable thus is not indexed by ezfind and/or other search engine plugins? Viewing the ezfloat datatype class i was missing the following two functions: isInformationCollector() isIndexable() Both should return true to enable indexing and information collection. I am using ezp 4.2 Thx, chris Hannover, Germany eZ-Certified http://auth.ez.no/certification/verify/395613
Nicolas Pastorino	Wednesday 17 March 2010 9:29:33 am Hi Christian! Yep, that is correct and pretty much is a bug to me. The issue seems old : http://issues.ez.no/IssueView.php?Id=3321&activeItem=2, you may want to comment there, and/or create a dedicated bug for your specific issue, and link it to the above. In terms of short-term solution: are you using eZ Find ? This could help you kinda work around this issue, in a slightly hackish manner. Let us know, Cheers, -- Nicolas Pastorino Director Community - eZ Member of the Community Project Board eZ Publish Community on twitter: http://twitter.com/ezcommunity t : http://twitter.com/jeanvoye G+ : http://plus.tl/jeanvoye
Christian Rößler	Wednesday 17 March 2010 3:19:14 pm Indeed I am playing with ezFind and implementing a nasty filter/facet search for Products and their ezFloat based Attributes using php + ez-api as business logic returning results directly into the templates using dedicated template functions. My question intenionally was why (technically) its not possible to search for ezFloats. I thought that adding a comment in the source would be sufficient to explain why, but did not found any so posted my question here. The provided url by Nicolas and following some links from there I was able to get a idea why this wasn't implemented yet. Surprisingly a patch is available for ezFloat (and ezPrice too?), also surprising is the age of this issue and a handful related ones (dated back to 2005). So I will try to override the ezFloat class and create a extension to be update secure. Plus i will try to get all the comments from the issuetracker and the patch(es) from there and create a up-to-date patchfile based on ezp 4.2. We'll see... btw: ezSelection Datatype is a b*tch too. Storing the selected values (foo,bar) as text/string in solr isnt a good choice. The keys (0,1,2) should be stored instead. I found some questions in the forum and a few issues in the tracker too I think. Most problems occur when the selection-value has whitespaces in it. Try to create a filter-search for that datatype using ezfind + when multiselection is enabled... what a mess ;-) Thanks for your reply Nicolas. -- Chris Hannover, Germany eZ-Certified http://auth.ez.no/certification/verify/395613
Christian Rößler	Wednesday 24 March 2010 6:53:06 am OK, this is he actual situation. I have managed to create the float datatype which is searchable and can collect information. I also created all the necessary templates. Everything is working fine. It is in QA / Test for a few days now. Now i am facing 2 issues which are left and partly have to be addressed to the ez-developers: L10n is playing mad with me. In germany we do have '.' as thousand separator and ',' as decimal separator. Other countrys might have it the other way around. This has to be addressed in the datatype-code itself when storing to DB and fetching the value from DB. Also all the templates need to address this issue. It is currently implemented in a few ezFloat templates, but seems not to work correctly. I can do this by enhancing my float-datatype-code and do some magic when fetching user-input and storing to database and when fetching from database to send to the templates... And there seems to be a bug in ezpublish, i filed a bugreport already: 16509 The problem is, that when the datatype is marked as 'not required' and the user has typed in nothing, a 0 (zero) is stored in the database, which is not correct. It should store null. The database schema supports those null-values, but the ezcontentclassattribute-definition describes 0 (zero) as a default value which in turn is choosen... But that is NOT what the user has typed in... This affects all numeric based datatypes (eZInteger, eZFloat, eZPrice, ...). I'll keep you posted. The Datatype itself is working. Searching and collecting information is available. Templates are fine too. I might need to wait for ez for feedback on the 0-vs-null issue before publishing it. I did not encounter any other issues yet. cheers, chris Hannover, Germany eZ-Certified http://auth.ez.no/certification/verify/395613